Crash whilst watching on time shift

[netmask]

Unfortunately my T3 didn't save a crash report so briefly this is what occurred
Watching Dr Who ABC1HD, phone rang so put it on pause. Then resumed play and continued to about 20 seconds before the end (gggrrrr) black screen came up with a sorry a reboot. Rebooted automatically and everything seems to be back to normal. Latest firmware is installed via USB. Did a search in logs for a crash report but not present. Early reports where there. Sorry not much to go on and it is the first crash in months. Maybe something to do with time shift? Once I resumed play after the phone call I didn't navigate or do anything with the remote.

[MrQuade]

black screen came up with a sorry a reboot. Rebooted automatically and everything seems to be back to normal.

So it did display a crash screen with all the text on it, or was it a black screen? Also, did it fully reboot, or was it just a GUI reboot? That sentence doesn't make it clear.

Did you check both /home/root/logs and /hdd/logs? Perhaps you changed it and forgot or forgot to change it after a firmware update?

[netmask]

Ha ha! You are right - just found it. I was looking in the wrong log folder.
So attached

Enigma2_crash_2017-06-18_20-24-00.log

(16.77 KiB) Downloaded 53 times

[netmask]

A full crash screen with all the text on it and not sure about just a GUI or a complete reboot as I rushed into my bedroom to attempt to see the finale of Dr Who ! It will have to be catch up I fear or tomorrow afternoon

[prl]

The crash happened when the box needed to change channels in order to do the recording and you hadn't already asked to save timeshift.

The code preparing the options popup for this case and crashes when testing whether to put the choice box choice "Save timeshift in movie dir and zap" before or after "Zap" option, and it tests on what seems to be an unimplemented method of InfoBar. The code seems to be incorrect in the same way in OpenViX.

The effect of the test is deciding whether the choice list order should be:
"Zap"
"Save timeshift and zap"
"Don't zap"
"Save timeshift in movie dir and zap"
"Don't zap and disable timer"
"Don't zap and remove timer"

or

"Save timeshift and zap"
"Zap"
"Don't zap"
"Save timeshift in movie dir and zap"
"Don't zap and disable timer"
"Don't zap and remove timer"

Implementation of the required InfoBar.timeshiftActivated() method (probably in the InfoBarTimeshift mixin) should be easy, and should probably be fixed in OpenViX, too.

[netmask]

Ah yes I had a regular timer for Dr Who but then had to go to timeshift when a predictable phone call occurred - in future aeroplane mode!. Then I had a zap timer only to ABC2 or whatever to watch Whovians. Crash! Thanks for the info I will workaround it in future......

[prl]

Ah yes I had a regular timer for Dr Who but then had to go to timeshift when a predictable phone call occurred - in future aeroplane mode!. Then I had a zap timer only to ABC2 or whatever to watch Whovians. Crash! Thanks for the info I will workaround it in future......

Yes, a zap timer (or zap+record) timer triggering on a different channel while you're viewing timeshifted will also exercise the same code (and should provide a simpler replication setup).

[prl]

Bug #592: Crash on zap in RecordTimer when timeshifted

[prl]

Curiouser and curiouser.

Although the test on InfoBar.timeshiftActivated() is intended to change the order of the choices, the code building the choice list is only ever called in situations where InfoBar.timeshiftActivated() should return True.

And also, there are two "save timeshift" choices, "Save timeshift and zap" and "Save timeshift in movie dir and zap".

The only difference between the two is that "Save timeshift in movie dir and zap" does:
self.InfoBarInstance.save_timeshift_in_movie_dir = True

Which seems sort-of reasonable, except that InfoBar.save_timeshift_in_movie_dir is never initialised, set anywhere else, or referenced anywhere else.

So it would seem that the correct way to fix the problem is to put the "Save timeshift and zap" in the choices list where it would go if InfoBar.timeshiftActivated() returned True, and to get rid of the "Save timeshift in movie dir and zap" choice and its associated code.

[prl]

I've verified this as a bug in OpenViX, too.

[prl]

This looks like the result of a merge from OpenPLi into OpenViX and thence into the Beyonwiz code that dragged in references to things in OpenPLi that OpenViX and Beyonwiz don't implement.

[IanSav]

Hi,

I think this is one of the reasons why PeterU doesn't take code from OpenPli. Their code base has significantly diverged from the OE-Alliance.

Regards,
Ian.

[prl]

Yes. That came to my attention when I was working on the EPGSearch plugin, which has a special version for OpenPLi.

[prl]

The OpenPLi-sourced incompatibilities just keep on coming. Once the code is cleaned up to allow it to actually try to save the timeshift buffer, that calls a non-existent InfobarTimeshift method.

[prl]

And on it goes. In order to reliably test my fixes, I've submitted a fix to Bug #490: Save current timeshift event sometimes saves the event's .sc file (where sometimes = ~50% of the time ).

I've also included the fix to Bug #375: Timeshift fails with misleading error message if timeshift location contains directory named "timeshift", which means that if the fix as a whole is accepted, it should slightly reduce the differences between the OpenVix Timeshift.py and the Beyonwiz one.

I've offered to make a minimalist fix for the #450 fix if the one I've submitted causes too many upstream merge issues for them, but I hope they decide to Do It The Right (aka My) Way

[IanSav]

Hi Prl,

While I haven't heard anything directly, your submissions to OpenViX are now getting fairly prompt attention and merges.

Regards,
Ian.

[prl]

... While I haven't heard anything directly, your submissions to OpenViX are now getting fairly prompt attention and merges. ...

Yes, I'd noticed, thanks. This one is slightly different since it does a lot more than is strictly needed to fix the timeshift save bug and is spread out in the code in a way that would tend to make upstream merges messier. Unless they push the changes upstream, too . Just fixing the bug is a one-liner. Though as a side benefit it fixes another, somewhat obscure bug, and stops eBackgroundFileEraser mangling directory links in some other slightly obscure cases.

Read all about it here.

[prl]

Huevos commented 5 minutes ago

Can you please the minimal bug fix... And maybe we can also push that to PLi if the bug also exists there too.

[IanSav]

Hi Prl,

Huevos commented 5 minutes ago

Can you please the minimal bug fix... And maybe we can also push that to PLi if the bug also exists there too.

Oh well, the rest of the fix can roll out as you continue to improve the OpenViX. We will eventually get it up to Beyonwiz specs.

Regards,
Ian.

[prl]

Hi Prl,

Huevos commented 5 minutes ago

Can you please the minimal bug fix... And maybe we can also push that to PLi if the bug also exists there too.

Oh well, the rest of the fix can roll out as you continue to improve the OpenViX. We will eventually get it up to Beyonwiz specs.
...

The problem is that the fix I submitted to OpenViX includes the fix for Bug #375: Timeshift fails with misleading error message if timeshift location contains directory named "timeshift", where the bulk of the changes in what I submitted to OpenViX are made. The actual Beyonwiz fix for Bug #490: Save current timeshift event sometimes saves the event's .sc file is just a small modification to that.

If the fix for #375 is rejected, it doesn't make much sense to fix #490 the way I'd like to. So the minimalist fix I submitted is just:

Code: Select all

diff --git a/lib/python/Components/Timeshift.py b/lib/python/Components/Timeshift.py
index e7624e1..4c37d20 100644
--- a/lib/python/Components/Timeshift.py
+++ b/lib/python/Components/Timeshift.py
@@ -610,7 +610,7 @@ class InfoBarTimeshift:
 			# print 'TEST1'
 			for filename in os.listdir(config.usage.timeshift_path.value):
 				# print 'filename',filename
-				if filename.startswith("timeshift.") and not filename.endswith(".del") and not filename.endswith(".copy"):
+				if filename.startswith("timeshift.") and not filename.endswith((".del", ".copy", ".sc")):
 					statinfo = os.stat("%s%s" % (config.usage.timeshift_path.value,filename))
 					if statinfo.st_mtime > (time()-5.0):
 						savefilename=filename


This leaves the testing for the "timeshift.XXXXXX" files as imprecise as it was before my #375 fixes.

[IanSav]

Hi Prl,

When I get back to Enigma2 development I can advocate for the fuller change in the OpenViX developer forum.

Regards,
Ian.

[prl]

I've already put a comment in the minimalist pull request that they reconsider the rejection of the first fix, but your support in the OpenViX forum would be welcome. Thanks.

[prl]

The minimalist fix for the bug that saves the wrong timeshift file has been merged into the OpenViX repository. At least now I can go ahead and submit the fix for the original problem.

[peteru]

All the OpenViX updates from Dev branch as of about this time yesterday have made it to the Beyonwiz next branch.

The Beyonwiz next branch was merged into master overnight and 17.5 build for the T4 has been made available.

The next step is to look at the backlog of pull requests against Beyonwiz master and start applying them. Hopefully these pull requests won't create too many conflicts with OpenViX merges later on.

[IanSav]

Hi PeterU,

I rebased my pending pull requests against the new master and there were no issues.

I need to check but I think one of the pull requests is already in the OpenViX merge you recently performed.

Regards,
Ian.

[prl]

...
The Beyonwiz next branch was merged into master overnight and 17.5 build for the T4 has been made available.
...

I rebased my pull requests after that merge of next onto master was done. There were no conflicts in the rebases.

[prl]

...
The Beyonwiz next branch was merged into master overnight and 17.5 build for the T4 has been made available.
...

I rebased my pull requests after that merge of next onto master was done. There were no conflicts in the rebases.

I did, but I forgot to pull first. I've now redone the rebases, and they show "changes already merged" for the fixes for #520 and #591. The pull request for #590 still needs to be applied.

[prl]

I have submitted fixes to Bug #592: Crash on zap in RecordTimer when timeshifted to the Beyonwiz and the OpenViX repositories.

[prl]

Fix merged into the Beyonwiz repository.