WanWizard

En dat heb je niet uit staan?

Rechts bovenin de dropdown met je naam openen, "Manage ignore prefs", en dan het checkboxje bovenaan uitzetten?

You have to see it this way:

When you manually zap away when a timeshift is running, you get a popup and you have the option to save, right?

The problem here is that the box decides to zap away (because of the recording that started) and nobody is there to deal with anything interactive. So you need a config option that says "if the box decides to zap when a timeshift recording is running, choose option X automatically without showing a popup".

You are a moron, and always will be.

I don't have any problem with my server being used by dreamboxes. All dreamboxes running OpenPLi can use it without problems.

I however don't see any reason why I should use personal funds to sponsor Dreambox (or their slaves like yourself) when they have openly dumped support for open source. You do exactly the same, with your tmpd checks and timebombs.

You know this very well, so no need to resort to stupid statements like this.

So be nice, and get lost.

Nobody told you to upgrade. Stop complaining.

We're very busy pulling VU+ into the 21st century, and that requires a lot of structural changes at the core of the image.

It was not directed to you, it was a general remark. And I have just explained the why...

Vanaf zo'n kleine 10 min terug lijkt met name het forum weer aanmerkelijk sneller. En blijkbaar zijn dit soort 'grappen' lastig af te vangen.

Ik ben nog druk bezig met vechten, dus het zal er nog wel een paar keer uitvallen, als er memory bij moet, of er iets herstart moet worden.

Ik had mijn zaterdagavond anders voorgesteld. Ik houd nog steeds die gute-idioot-mine hiervoor verantwoordelijk, het is frapant dat het alleen mijn xmltv mirror is die aangevallen wordt...

OpenPLi (OE + Enigma) != DMM (or VU+, or...). This means that in order to remain compatible with the closed source drivers of these manufacturers, we need to be able to see their source code, so we can reverse engineer and adapt our image for these drivers through the box' BSP layer.

Because DMM has decided no longer to support open source, and has gone closed source for their own image, this is no longer possible. OpenPLi therefore HAD NO CHOICE but to drop support for DMM hardware. You can not compare OpenPLi with DMM clone images (like the gemini's of old).

If DMM wants OpenPLi to support their hardware, we need that access, or alternatively that DMM maintains the BSP themselfs (like VU and Xtrend also do). We don't have a problem with that, by all means, have them contact us with their proposal.

Meaning: "developers of these plugins are paid by DMM in an attempt to force everyone to buy DMM, by actively blocking the use of alternative images, and frustrating the users wanting to use those images".

gutemine is such a developer.

solution: "nobody should be so stupid to buy DMM hardware, forced by people like gutemine. You can buy better hardware for a lower price with better image support". 

Voor alle OpenPLi4 boxen staat momenteel een waarschuwing aan.

In de image van vandaag zit een nieuwe versie van OpenEmbedded, die zorgt voor meer dan 300 updates. Het is aangeraden NIET te updaten maar de box opnieuw te flashen, omdat de kans groot is dat de update niet in een keer correct zal verlopen (en daarna een flash alsnog nodig zal zijn).

Dat klopt.

Standby is eigenlijk gewoon "aan", maar dan met video uitgeschakeld, en tuners die uitgezet worden als er geen opname loopt.

Dus als je 'm uit standby haalt staat de zender die op stond toen je 'm in standby zette nog gewoon op.

Even oppassen.

Je zit hier vast met e.o.a. tool naar te kijken, en dus mis je informatie. Als je dit in linux op de commandline zou opvragen, dan zie je:

lrwxrwxrwx    1 root     root            33 Jan 30 05:00 PLi-AutoBackup.tar.gz -> PLi-AutoBackup0016c997082e.tar.gz
----------    1 root     root        111155 Jan 30 05:00 PLi-AutoBackup0016c997082e.tar.gz
lrwxrwxrwx    1 root     root            23 Jan 30 05:00 autoinstall -> autoinstall0016c997082e
-rw-r--r--    1 root     root           485 Jan 30 05:00 autoinstall0016c997082e

Je ziet dus dat PLi-AutoBackup.tar.gz en autoinstall symlinks zijn naar de backup file met het mac adres van je box.

Die cijfer- en letterreeks is dus het MAC adres van je box. Hierdoor zijn de backup files uniek per box.

Dat ligt aan de setup van de router.

Als die router wel voor IPv6 geconfigureerd is (en dat worden er steeds meer) dan zal die zonder problemen ook IPv6 adressen terug krijgen op een DNS request.

Je haalt een aantal zaken door elkaar. De communicatie op IP niveau tussen client en DNS server (die zowel IPv4 als IPv6 kan zijn), en het DNS request dat de deur uit gaat.

Als de client een actieve IPv6 stack heeft, ook al zit daar alleen een link-local adres op waar je niks mee kunt, dan zal de DNS client een resolver request de deur uit doen voor zowel A als AAAA records. En dus zal je, als je een host probeert te resolven zowel de v4 als v6 adressen terug krijgen.

Nu is dit in dit geval acedemisch, ik heb even gecontrolleerd, alle download servers staan alleen met hun IPv4 adres in DNS (hoewel de servers zelf dus wel volledig dual-stack draaien).

I am not sure it will automatically create /media/netNASstream, I am very sure it will create /media/NASstream.

Other than that, you are correct, you have understood it fine.

No, it is not the only way.

This is why we introduced the BSP layer, and this is why we work very hard with the vendors to make sure all vendor specific stuff moves to the BSP layer. So you can get rid of the complex "if this box then do something special" mess in the code.

Not all vendors move at the same speed, especially VU+ needed a lot of convicing, but even they are slowely getting around.

I know it is easier, at least at the short term, to hack your way around instead of trying to convince the vendors they have to do something right, but this is exactly where the problem starts. And we refuse to do that.

This complexity, all these workarounds, and all the dependencies and conflicts between them (and this problem extends to the horror that is called a plugin) has caused us all to waste our valuable spare time working on this stuff, instead of on fundamental improvements to the E2 architecture, which is really needed to make better use of the hardware. And the more vendors and the more boxes you want to support, the uglier it gets.

This is true not only for E2 itself, but also for additions to it. Take for example the WebIf. How much easier would it be if its developers won't have to deal with all vendor stuff, but the vendor could include it's specific stuff (interface code, RC image, box image, etc) in the BSP. Then the OpenWebIf developers could dedicate their time to making the WebIf more functionally rich and awesome, instead of trying to figure out why the Duo2 has a transcoding icon, but the ET10K doesn't.

Don't forget there is a very nasty commercial business behind this all. All these vendors are laughing all the way to the bank that there are some "stupid" hobbyists that spend all their free time increasing their sales margins. Vendors crawl over each other at our front door to have an OpenPLi image for their box, simply because it significantly boosts sales. I'm pretty sure some other popular images see the same.

We refuse to play that game. Although for us it's not a commercial business, we want to deliver a product we're happy with, nee proud of, and if we can use the popularity of the OpenPLi brand to make the vendors carry some of the effort too, then we'll end up with a significantly better product, which is good for parties at both sides of the table.

And we have to look at ourselfs as well. There are a lot of very good developers out there, but instead of really working on an open source project, they all fork the code, and start re-inventing each others wheels. Which is an enormous waste of time and talent. If we all could come to an understanding that instead of all these forks it would be better to work on a single product, there would be dozens of very talented developers available to make "the E2 product" absolutely awesome.

This was our main idea behind going from PLi to OpenPLi and be completely open. And this can only be archieved if we can get rid of all vendor specifics in the code, which has been our main focus for the last year (or so).

This requires not only a lot of blood, sweat and tears trying to steer the vendors, it also requires the developers to come up with solutions to move all vendor specifics to the BSP. Like in the example of the WebIf, that will only work if its developers will make the WebIf modular, with a separate class or package for vendor specific stuff, and with a clearly defined interface and implementation, so every vendor can easily add it to their BSP.

And what does that help us?

If you know so well how it works there, why not donate the code to OpenPLi? Or send in a patch, OpenPLi is open source (unlike DreamOS, of which I am very sure it contains GPL code, so it violates the license).

If you can't be constructive, please go somewhere else. Like they say overhere "we can miss you like a toothache".