Merged, built, tested it.
Excellent, it will use all three tuners on a single rotor now.

Anyone dare to comment? Confirm? Deny? Hello?

If I configure a DM8000's tuners as follows (you do not need an actual rotor to test this, just pretend it's there):

A = Rotor
B = linked to A
C = Second cable from rotor A

No matter what i do, tuner B will never be used. This configuration should allow me to record from 3 transponders simultaneously, but Enigma2 only allows me to use 2 tuners. For example, when two recordings are running it shows A and C in use, but it only allows me to use those two transponders.
A workaround is to LIE to Enigma2 and claim that C is just a dish pointing at 19E for example. In that case, I can use all three tuners as expected, but this will lead to failed recordings when the rotor turns away from 19E.

It's a bug, because E2 allows me to set this configuration, but it does not work. Obviously, I hope that it can be fixed by making it work rather than just forbidding the configuration...

SAme here. The thing is not glued properly - in fact, i think it's the thick layer of goo that interferes with it.

This bug has been in E2 for a long time, just bumped into it this morning by accident.

To reproduce:

Attach a DVD player or something similar, and have it play back, so that the scart signal is activated.
The option "automatic scart switching" must be enabled.
Restart enigma2 (e.g. using the web interface), and the box will crash, reboot, crash, reboot, etc...

Workaround:

Disable the autmatic scart switch option (not quite as handy) and set the box in standby to watch DVD.

For many users it's a nice feature to see whether they were halfway through or finished watching an event. Me and my wife like it a lot - we can immediately see where we stopped last time. It's particularly helpful when there are multiple users interested in separate events.

The blue icon means that either:
- You started playback but stopped playing in less than a minute.
- You played the recording until the very end
- Some software 'touched' the files in a way that i cannot interpret
- I have to change something in Enigma to draw the correct conclusion.

Since this is ongoing work, the blue icon will eventually be replaced...

The symbols indicate how much of the recording you (appear to) have watched. So if you're halfway, you get the half moon symbol. The read dot is for a "brand new" recording.

Create your own icons and send them to me if you think you can do better.

Just use Python's "os" module, it's much easier to use and you don't need a running Enigma2 to test your code.

The OpenPLi one is the movie list I made. The icons still need a little rework.

You (DMM) can just grab it from the openpli repository and include it in the main line, you'll make a lot of users happy.

It also adds a simple automatic tagger.

Every time i see the Language selection screen, I wonder: Why?

Why does it change the language for displaying languages when selecting a language? Changing the title and the instructions is nice, but being forced to guess your country's name in Bulgarian when the cursor happens to pass there is just a pain. The flags are nice eye-candy, but it's the text I'm actually looking for.

I would expect the following:

- English
- Francais
- Deutsch
- Nederlands
- etc....

Each language is simply displayed in its own language, and never, ever translated into something else. Don't switch. Please. Stop it!

With the latest enigma2 and openembedded (gstreamer 0.10.25), attempting to play an MP3 results in an error message that the "autoaudiosink" is not installed, and enigma2 hangs. Have to kill it to get the system up again.

I'm looking for a way to run some processing code in background in Enigma2. So far with little luck.

Simply using threading appears to be 'disabled' when running from Enigma2 (works file in a standalone Python process though).

I tried using the reactor, which helps a bit, but the program needs a lot of processing for small amounts of data, so the UI becomes sluggish and i still get the rotating wheels. Besides that, it's a real pain in the youknowwhere to have to revert all code from pulling data (read) to being pushed.

Running the code from another process is an option, but it wastes a lot of precious RAM on copies of things that are already loaded into Enigma2, and it makes communication with the background process more complicated.

I wonder what else I can do. I also considered creating the thread in C++ code and calling back into my Python code from there, so that the Python processing part also runs on that thread. Would that be an option?
Another thing that came to mind was a sort of "Idle" call, which calls a method when the reactor is idle, so that code there can execute in little bits (windows 3.1 style multitasking).

Any takers?

Solved after adding /etc/asound.conf (fraxinas)

Ever since this change:

http://git.opendreambox.org/?p…a3841096e9792804f3d0e51dd
"experimentally switch to new decodebin2 gstreamer back-end for mediaplayer..."

the media player on the 7025 can not play back MP3 files.

This is probably because the "disable hardware decoding" patch no longer applies on the Enigma2 code.

Is there a description of these objects somewhere?

eAppContainer seems to run a separate process (i.e. fork, not thread).

Might be the power supply.

I had the very same problem, i first thought it was the image, but it's probably the "being down for a while" that brings back the speed.

Replacing the capacitors on the power supply really fixed this problem.

Same here, I haven't been able to generate false positives with that latest change. Thanks, also from a few hundred other users who are using my image.

Hello,

I want to do some processing which cannot take place in the main thread. The processing I want to run in background is basically something like:

while 1:
  d = file.read(64)
  songname = d
  d.file.read(buffersize)
  pipe.write(d)

(the pipe goes to the MP3 decoder, that part is working just fine)

I saw something about timers, which is rather clumsy to use here, as the code will be cluttered with all kind of clumsy things to prevent blocking the main thread waiting for incoming data, while still feeding the pipe fast enough...

The current solution is to have another process that runs that "processing", but that is much harder to use, and it's a pain somewhere to communicate with the background process, while a thread is exactly what i want here...

I tried using Python threading, that is working just fine outside of Enigma, but when I put the threading code into a plugin, the thread function just never gets called at all. Apparently, Enigma2 plainly refuses to create threads?

I have the same problem. Any recordings like these:

<===A===> <===C===>
<======B=====>

where B needs the second tuner will fail the check.

Simply throwing away the sanity check code fixes it too, it will record just fine then!

Trust us, the timersanitycheck code is broken.

(I can read German, but writing is beyond my capabilities).

Confirmed, bitbaked a new image and it works okay again.