Looking at todays driver changelog, I might have drawn the wrong conclusion about the bootloader being the cause of the problems.

well, lets hope there were a few more changes than just that.
It's never a good sign if small changes cause big problems.

It seems that with the recent bootloader version 75, the number of boot problems has significantly increased.
Not talking about the situation where the box doesn't switch on when the power is plugged in, we all know how to deal with that.
But another problem, which we used to have a long time ago, where the box boots normally, but /etc/init.d/bootup crashes before it can load the drivers, so the boot process stops with the process bar at something like 25%.
This problem had been gone for several bootloader versions, but now with 75 it seems to be back.

Many users have reported a significant increase of this problem, since we upgraded from 74 to 75.

Zitat

I just wanted to change this behavior but unfortunately it already saves its configuration when you leave the overview without canceling (keySave -> green button afair). At least it should - if it does not I don't know how I could help you...

Hm, you're right, thats weird.
The only way is to call configfile.save(), but it shouldn't have to be that each plugin has to call that...

I think the best solution for this (general) problem would be if ConfigSubsection.save() (or even better ConfigSubsection.__del__) would call configfile.save(), but only if something actually changed.
That way, exitting the setup menu no longer would have to explicitly call configfile.save(), so on avarage, we'd probably even reduce the total number of configfile saves.

weird, everything just works fine, so no action needed.

Apart from the case sensitive search bug, but so far nobody has used that I think.

weird, there hasn't been any change in that area for a year at least.
I do see a bug however in eEPGCache::search, but looking at the code it should only affect case sensitive searches, not case insensitive searches.

I'll have a look and try to debug why it doesn't find case insensitive matches.

Zitat

Originally posted by ritzMo
Saving only when e2 shuts down was a design decision and I don't really see a reason to change it. It's the same with e2 and why should a plugin be any better?

It used to be like that, but fortunately more and more settings are now saved right away.
The setup menu for instance, saves all changes when you exit the menu.
Timer changes are also synced immediately.

With an application like e2, which runs for weeks/months till you get a power failure (or a BSOD), settings should really be saved right away I think, we cannot expect the average user to do a clean restart after each little setting they change

Zitat

Implementing a per-service delay is a big mess on the GUI side... actually I don't know how I was supposed to do so - a new screen just for the delay is weird and putting it on the existing one is pretty unreadable.
The Plugin tries to update only one channel of each transponder so adding a channel multiple times should not work.

Let me give you a bit of background, what I'm trying to achieve.
Low bandwidth epg streams (such as freesat) can take up to 1 hour to complete.
Most others don't need more than 1 minute.
Having 4 or 5 different epg services configured, I would need to configure a 1 hour delay, and the receiver would be watching tv pretty much all night
(Allowing to add the same channel several times might provide a workaround, but in that case we should probably avoid a 'zap' in between, to avoid epg readers to be stopped and restarted)

Didn't the autotimer use to have case-insensitive searches?
I noticed that with the current version timers are only added if there is a case sensitive match.
Since I use several 'record everything with xyz in it' entries, I have to create duplicate entries with all case combinations at the moment. Perhaps case sensitivity could be an option?

-settings are not saved till e2 restart (so they are lost after a crash, I never restart e2 till it crashes)
-some EPG services take longer than others, it would be nice to have a duration per channel
(adding the same channel several times seems to work as a workaround at first, but after restart duplicates are removed)

Zitat

Originally posted by eagle

How to?

with stat for instance. There already is an example in the harddisk manager, where major/minor is checked / compared I believe, for the mountpoints. The same should be done for the harddisk devicenode.

for the 7025, the hdd is not disc0, but 1 or 2 or even 3 (depening on which drivers are loaded, and/or block devices are found)

The real solution is to fix the harddisk manager, to find the mounted devicenode (by comparing major/minor), instead of using the fstab devicename.

what do you mean, it doesn't work?
Does the pull fail?
Does the build fail?

If you mean that e2 is still pulled from cvs instead of git, and therefore you don't get the latest commits, I suggest you change the SRC_URI, or use obi's branch for instance http://git.opendreambox.org/?p=obi/opendreambox-1.5.git

git pull instead of mtn pull. No arguments needed, if you've created a '--track' branch.

btw, if you're using the wrapper makefile, just use 'make openembedded-update', just like with the mtn wrapper makefile.

that's a different issue;

Error bei rootfs....

have a look in packages/fakeroot/
I'm currently using 1.7.1 for both fakeroot and -native.

bootup is installed by initscripts-opendreambox.bb

the problem is the new .nfo file generation in dreambox-image.bb.
It tries to find an e2 version string, which obviously isn't there for e1 images.

For now, just comment the e2version stuff at the bottom of packages/images/dreambox-image.bb

Zitat

Originally posted by Wilko
Same here kan anyone help please ??

for the original error? Update fakeroot and your problems are gone.
For AliAbdul's error? I don't see how IMAGE_ROOTFS_SIZE_ext3 does anything, as we're not building an ext3 image. But it helped for him, so it might work for you as well.

thx for the quick fix

File "/usr/lib/enigma2/python/mytest.py", line 172, in processDelay
callback(*retval)
File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 1252, in extensionCallback
File "/usr/lib/enigma2/python/Tools/BoundFunction.py", line 9, in __call__
File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 1273, in runPlugin
File "/usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/plugin.py", line 78, in main
File "/usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/AutoTimer.py", line 95, in readXml
File "/usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/AutoTimerConfiguration.py", line 53, in parseConfig
File "/usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/AutoTimerConfiguration.py", line 91, in parseEntry
NameError: global name 'maxlen' is not defined

code:

maxduration = element.getAttribute("maxduration") or None
if maxduration:
baseTimer.maxduration = int(maxlen)*60

looks like a maxduration-->maxlen typo?