34 replies to this topic

[jamu]

Hi,

 

I've come across the following behavior on my VU+ Uno4KSE when playing back recordings made on the same device from DVB-T channels using MPEG2 encoding. Recordings from DVB-T2 channels with AVC encoding do not show the same problem. The system is using OpenPLI 7.0 with the latest 2019/03/18 updates.

 

Enigma2 freezes with 100% accuracy whenever rewinding any of the MPEG2-based recordings. This happens regardless of speed, even at 2x. The freeze usually happens within a few seconds of starting the rewind, but sometimes - rarely - can take even a minute before finally freezing. Forward-seeking works fine at all speed. I have not have the problem trigger when skipping backwards with the number keys.

 

When Enigma2 freezes, the spinner appears, and the only way to recover is to "kill -9" the enigma2 process -- or reboot.

 

Any hints at how to troubleshoot this further?

 

Debug logging from the time rewind was triggered from one of the recent tests:

 

action: seekBack
[ActionMap] Keymap 'InfobarSeekActions' -> Action = 'seekBack'
[eDVBServicePlay] setFastForward -2
[eDVBServicePlay] setFastForward setting cue skipmode to -2
[eDVBChannel] skipmode ratio is -180000:90000, bitrate is 2656857 bit/s
[eDVBChannel] resolved to: -591788 524288
[eDVBChannel] flush pvr
[eFilePushThread] waiting for pause
[eFilePushThread] PAUSED
[eDVBAudio0] AUDIO_CLEAR_BUFFER ok
[eDVBVideo0] VIDEO_CLEAR_BUFFER ok
[eDVBChannel] done
[eTSMPEGDecoder] decoder state: trickmode, vpid=020e, apid=02d6
[eDVBAudio0] AUDIO_STOP [eDVBChannel] ok, resolved skip (rel: 1, diff 18993125), now at          414fbec
ok
[eDVBAudio0] DEMUX_STOP ok
[eDVBAudio0] AUDIO_CONTINUE ok
[eDVBAudio0] destroy
[eDVBText0] DEMUX_STOP ok
TuxTxt stopped service 1392
[eDVBText0] destroy
[eDVBVideo0] VIDEO_SLOWMOTION 0 ok
[eDVBVideo0] VIDEO_FAST_FORWARD 1 ok
[eDVBVideo0] VIDEO_CONTINUE ok
resolved to FAST FORWARD
[eDVBChannel] pvrEvent evtStopped
[gRC] main thread is non-idle! display spinner!

[jamu]

Inspired by https://github.com/O...ma2/issues/1904, I tried to remove a the .ts.sc file from a problematic recording. Once removed, rewinding no longer got stuck on the few tries that I gave it. As the rewinding previously got stuck 100% of the time, this clearly had an impact. As a side-effect, removing the .ts.sc file made the picture quality while rewinding terrible. PQ when forward seeking was same as earlier.

 

This is clearly not the correct solution to the problem, but possibly an interesting finding.

 

Any thoughts anyone? My setup should be about as standard as it gets, and is an almost out-of-the-box configuration. It feels odd if no-one else has the same problem.

[betacentauri]

Maybe .sc file is corrupt. You can recreate the file via the reconstructapsc plugin on the feed. Install it, then select the movie (not start) and press menu. There you find a menu entry to recreate the .ap and .sc files.

Edited by betacentauri, 25 March 2019 - 17:45.

[betacentauri]

After re-reading the post. Does it really happen on all MPEG2 recordings? Can you make a short recording (1-2 minutes) and test again. If that also makes problems, we need that .ts file to be able to find the bug.

[jamu]

I initially thought that the freeze happened on all MPEG2 recordings, because it did do so on all the 10+ recordings I had made earlier from two Finnish broadcast channels.

 

After trying a third channel today, it's not that clear anymore. I could not get the recording I made from this third channel to freeze enigma, even after multiple attempts. This was a short recording though, only 5 mins, so that could be a factor. Also, there was something clearly different in the recording from this third channel compared to the ones that froze enigma; this one had very jerky rewind playback, while the ones that froze rewinded smoothly (up until the point it froze). 

 

Anyhow, I made a short recording (3 min) from a channel that consistently (100%) froze with all my earlier recordings. Weirdly enough, this short recording did not crash every time -- maybe only 2/3 of the times I tried. But that could be simply because it's too short to consistently reach a state where the freeze happens.

 

The recording is available here: https://www.dropbox....-movie.zip?dl=0

[betacentauri]

I could reproduce 2 times on a gb quad 4k. But I needed at least 10 tries. Do you have enabled subtitles? Does it also happen when you disable subtitles?

[betacentauri]

Well, it seems also to occur when subtitles are disabled. Mhm, strange issue...

[jamu]

What speed did you use in your tests? Trying again, I get similar results when rewinding at 2x, but at 4x I got 100% (5 out of 5) - each time freezing at the approximately same mark of about 2:04 with the example recording.

 

Fast-forwarding feels buggy too. Try 16x FF on the this recording for example; playback ends before 1:30, even before the recording is half-way through, and just skips to the end. I've noticed other recordings, particularly mpeg2 recordings, behave in the same manner when using higher speeds.

[jamu]

Also, when 2x rewinding did not freeze, I noticed that the rewind stopped each time at 0:40 - which is less than 80% through - and skipped to the end. This doesn't feel correct either.

[mrvica]

I ran it through projectX (good old tool for fixing streams, not for HD suitable)), hier is the log, there are some subpicts inside (subtitles I think), could be causing the problem

 

 

Attached Files

•  log.zip   2.11KB   2 downloads

[betacentauri]

Yes, I used 2x.
Was it an encrypted transmission?

According to e2 log it looks like sc file contains wrong informations. I will recreate it, but I don’t think that will fix the problem.
Is not easy to fix such problems. On the weekend I hopefully have enough time to look at it.

[jamu]

Was it an encrypted transmission?

 

No, this was not from an encrypted channel.

 

Let me know if I can help in anyway - I can make additional recordings etc. if that will help narrow the problem down.

[betacentauri]

If I can reproduce it every time, it makes things easier. Will try with 4x.

Problem with debugging is, that I need to find the infinite loop that seems to run. There might be several places where it can occur. It might have something to do with the subtitles or with the sc files or something else.

[betacentauri]

With 4x rewind I also can reproduce it every time.

 

I tried to fix the bug, but until now I wasn't successful. Either rewind totally stops working or bug is still present.

Biggest problem is that I don't know why some things are done in the code.

[jamu]

Thanks for giving it a shot. Let me know if there's anything else I can help with to figure this out; Finland is apparently stuck with DVB-T for quite a few years still, as the transition to DVB-T2 got pushed back from the earlier schedule.

 

I have a bit of a programming background myself, if you can point me at the right part in the code base I could take a look as well. The problem for me is that the Enigma2 codebase, particularly the core C++ part isn't really documented, so the barrier to find how things are supposed to work is quite high.

[betacentauri]

Problem is that this while loop turns into infinite loop:

https://github.com/O...stools.cpp#L910

The findFrame always returns the same offset.

 

I think I have a solution:

https://github.com/O...stools.cpp#L879

Change it into

if ((direction >= 0 && start <= _offset) || (direction < 0 && start >= _offset)) return -1;

Which means: "Returning same offset is also an error". In my test it solved the problem.

 

 

But I'm quite sure that there are more bugs in the code. Maybe your observations (rewind stops 30 seconds before start of the file) are also caused by these bugs. Every try to fix them was not successful.

 

Maybe a short explanation. Rewinding don't work in the hardware. The c++ code searches for the next I-frame (backwards) and skips some of them depending on the rewind speed. Then I think the found I-frame is send to the HW decoder to show it on the TV screen and the code starts from the beginning (search).

This is the search loop:

https://github.com/O...s.cpp#L820-L846

 

But now I get problems understanding the code. After the search the code searches for the next frame:

https://github.com/O...stools.cpp#L849

Why? It makes no sense to me. And the found offset is not used. The variable start is used (line 882).

I thought it's useless and I have removed the do loop. Afterwards the rewind don't work at all. It immediately skips to start of the file. So the code has a sense which I don't understand

Edited by betacentauri, 1 April 2019 - 18:26.

[jamu]

Thanks, that was interesting to look into.

 

Why? It makes no sense to me. And the found offset is not used. The variable start is used (line 882).

I thought it's useless and I have removed the do loop. Afterwards the rewind don't work at all. It immediately skips to start of the file. So the code has a sense which I don't understand

 

Did you notice variable len on line 881? It uses offset, and it's passed to findFrame as a pointer, which means it gets passed back to the calling function findNextPicture, and looks like it's used there. This could explain why removing the do-while loop behaved the way it did.

 

I'll try to find time to look at the closer this week, but am unfortunately quite busy with work for the next couple days.

[betacentauri]

Good that we speak/write about it
That maybe do the trick. And now I know that len contains the length of the I-frame. Adding a comment would be good.
I’ll try to look at it again in the next days.

[betacentauri]

Now it looks much better . I think I have fixed the bug. Patch is not online yet.

 

But still rewind and fast forward stops in some cases several seconds before start/end. This seems to be other problem.

[jamu]

Excellent! Are updates to the enigma2 binary something you can ship as an update to the 7.0 release, or will we need to wait for 7.1 for this fix?