birdman
Moderator
Yes please, so I can see where file the file it reports the problem.
Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...
[Mut@nt HD2400] Software crash when fast forward a recording
- Thread starter rico_3000
- Start date
baz2011uk
Forum Supporter
- Joined
- Oct 29, 2015
- Messages
- 117
- Reaction score
- 0
- Points
- 0
Just dropped you a PM birdman
birdman
Moderator
Well, I've been sent an "offending" recording, run through it backwards at 16x(twice) and 8x, and all hung.
So something to work on....
One thing I did note was that the spinner doesn't get cleared when I run init 4/init 3 to restart enigma2. Does anyone know of any way to clear whatever is doing this other then a full reboot?
So something to work on....
One thing I did note was that the spinner doesn't get cleared when I run init 4/init 3 to restart enigma2. Does anyone know of any way to clear whatever is doing this other then a full reboot?
Last edited:
@birdman On Saturday I was watching a recording from 30.0 and by mistake went above 4x and the spinner got stuck as usual , I left it for about 1h to see if it would stop and go back to normal tv but it didn't I had to power off the box and back on
Sent from my TIMEBOMB!!!
Sent from my TIMEBOMB!!!
. .
Code:
http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4birdman
Moderator
That's what C++ destructors are for.Code:http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4
Well, I suppose I'll find out shortly....
birdman
Moderator
Well. By adding a call to disableSpinner() (in gDC::~gDC()) I got rid of the spinner. Or rather, I got it to stop on init 4, then it started performing "as normal" as init 3 started up enigma2 again.
BUT - it also managed to totally remove the actual picture (and the showiframe background image). Menus worked OK, but no picture.
All cleared by rebooting, but that's what I'm trying to avoid.
In the meantime I did find that the looping recording keeps going through the is_mpeg2 block in eDVBTSTools::findFrame(). It does exit it each time, so the loop problem is somewhere else.
birdman
Moderator
Well, I can now see what is happening. When looking for a suitable(?) Iframe it sometimes moves forwards (when it is running backwards overall).
And it can get to the state where it does neither:
However, there is more to it than that, as this sequence occurred earlier:
And it can get to the state where it does neither:
However, there is more to it than that, as this sequence occurred earlier:
and it somehow handled getting to 393154835 twice....
birdman
Moderator
Making progress.
I've found out (roughly) what the structure of an MPEG-2 TS file looks like and added various other debug statements to work with that.
Then discovered that the positioning is actually done with the help of the ts.sc (and ts.ap?) files, so I've found out what they look like (and have scripts to print out the info). They both look OK, so hopefully I can now find out why the code loops when looking for the "next" frame to display.
Mind you, as I work on this I do start to wonder how it actually does do 2x, 4x etc., as you can't just skip frames.- since most of them depend on you knowing what the previous/next one looked like it still has to calculate them. I also have no idea whether any of this is done in hardware - hopefully I don't need to know this in order to find the bug.
I've found out (roughly) what the structure of an MPEG-2 TS file looks like and added various other debug statements to work with that.
Then discovered that the positioning is actually done with the help of the ts.sc (and ts.ap?) files, so I've found out what they look like (and have scripts to print out the info). They both look OK, so hopefully I can now find out why the code loops when looking for the "next" frame to display.
Mind you, as I work on this I do start to wonder how it actually does do 2x, 4x etc., as you can't just skip frames.- since most of them depend on you knowing what the previous/next one looked like it still has to calculate them. I also have no idea whether any of this is done in hardware - hopefully I don't need to know this in order to find the bug.
Last edited:
ccs
ViX Beta Tester
- Joined
- Sep 6, 2014
- Messages
- 5,836
- Reaction score
- 5
- Points
- 0
I posted ages ago in this thread, and now that real progress is being made it might be worth repeating....
For me, x2 and x4 start straight away. When I go to x8, the picture goes back to x1 for about 3 seconds before x8 kicks in.
For me, x2 and x4 start straight away. When I go to x8, the picture goes back to x1 for about 3 seconds before x8 kicks in.
birdman
Moderator
Just guessing, but probably because one is an MPEG-2 stream and the other an H.264. These do have different start code structures and the mpeg one goes through additional frame-finding code (which is where I suspect the issue is).
birdman
Moderator
You could always use 3,6,9 (forward) and 1,4,7 (backwards) to skip instead.
baz2011uk
Forum Supporter
- Joined
- Oct 29, 2015
- Messages
- 117
- Reaction score
- 0
- Points
- 0
fair play mate as its all well over my head glad the files i did are helping to find out where the issue may lie and thank you for taking your own time to look into this
birdman
Moderator
I can see the problem. Both in the file structure and in the enigma2 code.
The file is an MPEG2-TS stream, with mpeg2 video (and some audio stream - which don't come into play). Such a file is a series of 188 byte packet. Packets contain headers which say what they are (or, if they are the data part of the video, which stream - PID - they belong to).
mpeg2 stream have 3 sort of video-frames I-, which are "stand-alone", P- which contain just contain the differences from an earlier frame and B-, which contain differences from earlier and later frames. So to play a stream you need to start at an I-frame. This is what the enigma2 code is looking for.
But it does it in a truly Byzantine manner. Despite having a an ordered list of the location of all the I-, P-, and B- frame headers it seeks backwards and forward through this list counting how many frames it has skipped over (and includes sequence header and group frames in the count when it probably shouldn't - depends on what nr_frames is counting, which isn't clear at all).
And then along comes a file with a group of pictures which just contains an I-frame - nothing else (something IBBPBBPBB is more usual). So if the fast-backwards gets to the I-frame after this, the code start where it is, goes to the previous frame (the single I-frame), goes forward from there to the next frame. It is now back where it started. It returns this info and the frame gets displayed (presumably). The file offset is now back at the the original I-frame and we just get stuck in that one position.
I have implemented a fix such that if findFrame() finds it has got back to where it started (or beyond) it goes through the code again, but this time with the offset of the earlier I-frame it found. A terrible kludge (it uses a goto to jump backwards...), but it's no worse than the rest of the code in that area. And it does work (at least for that Home&Away recording).
I have a distinct feeling that the code could be re-written to be much simpler and cleaner.
The file is an MPEG2-TS stream, with mpeg2 video (and some audio stream - which don't come into play). Such a file is a series of 188 byte packet. Packets contain headers which say what they are (or, if they are the data part of the video, which stream - PID - they belong to).
mpeg2 stream have 3 sort of video-frames I-, which are "stand-alone", P- which contain just contain the differences from an earlier frame and B-, which contain differences from earlier and later frames. So to play a stream you need to start at an I-frame. This is what the enigma2 code is looking for.
But it does it in a truly Byzantine manner. Despite having a an ordered list of the location of all the I-, P-, and B- frame headers it seeks backwards and forward through this list counting how many frames it has skipped over (and includes sequence header and group frames in the count when it probably shouldn't - depends on what nr_frames is counting, which isn't clear at all).
And then along comes a file with a group of pictures which just contains an I-frame - nothing else (something IBBPBBPBB is more usual). So if the fast-backwards gets to the I-frame after this, the code start where it is, goes to the previous frame (the single I-frame), goes forward from there to the next frame. It is now back where it started. It returns this info and the frame gets displayed (presumably). The file offset is now back at the the original I-frame and we just get stuck in that one position.
I have implemented a fix such that if findFrame() finds it has got back to where it started (or beyond) it goes through the code again, but this time with the offset of the earlier I-frame it found. A terrible kludge (it uses a goto to jump backwards...), but it's no worse than the rest of the code in that area. And it does work (at least for that Home&Away recording).
I have a distinct feeling that the code could be re-written to be much simpler and cleaner.
birdman
Moderator
My attempts to disable the spinner if enigma2 is "killed" work OK (call disableSpinner() in gRC::~gRC()).. HOWEVER, this just leaves things in a state where the TV picture doesn't display when enigma2 is restarted!! (menus etc. show up OK).
Code:http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4
I noticed this in the log when it happens:
Code:
< 521.045359> [eDVBVideo0] VIDEO_PLAY failed: Operation not permittedbirdman
Moderator
Still a work in progress....
I'm still looking at the FF/FR code (with the object of tidying it up).
In the process I have found what might actually be the cause of the original issue.
The problem is that findFrame() calls getStructureEntryNext(offset, ....) to get the next frame (so that it can get a length for the current one). THEN, if we have an mpeg, it calls getStructureEntryFirst(start, ....), the object here being to roll back start to the preceding sequence header. BUT, these two routines share an index into the cache file, so in fact the second call actually works back from offset, rather than from start (which is what it really intends to do).
It's possible that correcting this (which is possible) would fix the rewind hang. I'll need to test. At the moment my attempt at tidying up the code seems to have found a bug in the binary chop code in getStructureEntryNext(), so I'm checking that out too.
I'm still looking at the FF/FR code (with the object of tidying it up).
In the process I have found what might actually be the cause of the original issue.
The problem is that findFrame() calls getStructureEntryNext(offset, ....) to get the next frame (so that it can get a length for the current one). THEN, if we have an mpeg, it calls getStructureEntryFirst(start, ....), the object here being to roll back start to the preceding sequence header. BUT, these two routines share an index into the cache file, so in fact the second call actually works back from offset, rather than from start (which is what it really intends to do).
It's possible that correcting this (which is possible) would fix the rewind hang. I'll need to test. At the moment my attempt at tidying up the code seems to have found a bug in the binary chop code in getStructureEntryNext(), so I'm checking that out too.
Similar threads
