[Mut@nt HD2400] Software crash when fast forward a recording

[twol]

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).

I noticed this in the log when it happens:

<   521.045359> [eDVBVideo0] VIDEO_PLAY failed: Operation not permitted

so presumably something isn't shutting down the device properly when enigma2 is killed?

As previously posted Openpli are also discussing this and looking at how to terminate Enigma.... .. I think betacentauri is going to/has written some code

 

[birdman]

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.

It does!!

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.

Still working on that bit, but it does look like a problem (although I'd have expected it to have been encountered more often, so .....)

 

[birdman]

Still working on that bit, but it does look like a problem (although I'd have expected it to have been encountered more often, so .....)

I've tracked that down now too. The binary search is written with low + extent, but on the index adjustment thinks it is running with low and high (so there's an off-by-one bug).

Patches later (soon) once I've tidied everything up and done some final testing.

 

[twol]

I've tracked that down now too. The binary search is written with low + extent, but on the index adjustment thinks it is running with low and high (so there's an off-by-one bug).

Patches later (soon) once I've tidied everything up and done some final testing.

Congrats, now about the next 100 bugs

 

[birdman]

Fix

Patches later (soon) once I've tidied everything up and done some final testing.

Here they are:
View attachment FF+FR.zip
Whereas I can see how these would make fast-rewind hang (and could reproduce it...) I'm not so sure about fast-forward (which is simpler to code and less likely to end up in a loop). The only log in the thread is for a fast-rewind hang.

The patches are small, so here's the text.

--- tstools.cpp.orig    2016-03-22 15:53:35.531238005 +0000
+++ tstools.cpp 2016-03-22 16:14:31.033506752 +0000
@@ -860,6 +860,14 @@
 
        if (is_mpeg2)
        {
+// First we have to get back to where we were when we set start above
+// getStructureEntryNext has a private variable to remember where it was at the
+// end of the last call, and getStructureEntryFirst will set this correctly
+               if (m_streaminfo.getStructureEntryFirst(start, longdata) != 0)
+               {
+                       eDebug("[eDVBTSTools] findFrame getStructureEntryFirst for is_mpeg2 failed");
+                       return -1;
+               }
                // Seek back to sequence start (appears to be needed for e.g. a few TCM streams)
                while (nr_frames)
                {

--- pvrparse.cpp.orig   2016-03-07 17:33:55.792854000 +0000
+++ pvrparse.cpp        2016-03-22 16:03:40.853748710 +0000
@@ -413,7 +413,8 @@
                while (count > (structure_cache_size/4))
                {
                        int step = count >> 1;
-                       ::lseek(m_structure_read_fd, (i + step) * entry_size, SEEK_SET);
+// Read entry at top end of current range (== i+step-1)
+                       ::lseek(m_structure_read_fd, (i + step - 1) * entry_size, SEEK_SET);
                        unsigned long long d;
                        if (::read(m_structure_read_fd, &d, sizeof(d)) < (ssize_t)sizeof(d))
                        {
@@ -423,9 +424,12 @@
                        d = be64toh(d);
                        if (d < (unsigned long long)offset)
                        {
-                               i += step + 1;
-                               count -= step + 1;
+// Move start of range to *be* the last test (+1 more may be too high!!)
+// and remove tested count
+                               i += step;
+                               count -= step;
                        } else
+// Keep start of range but change range to that below test
                                count = step;
                }
                //eDebug("[eMPEGStreamInformation] getStructureEntryFirst i=%d size=%d count=%d", i, l, count);

 

[birdman]

Whereas I can see how these would make fast-rewind hang (and could reproduce it...) I'm not so sure about fast-forward

I suppose I should have tried it...so I just have on that Home and Away test file. It hangs going forwards too (on an unpatched image)....

 

[Rob van der Does]

Did you check on PLi? They recently seem to have fixed a (very) fast forward issue (even up to 128 times for TS).

 

[birdman]

Did you check on PLi? They recently seem to have fixed a (very) fast forward issue (even up to 128 times for TS).

No, I didn't. The code is quite convoluted in what it is doing, and anything that looks at all different would be a nightmare to compare.
The OpenPLi diff for what they did might be be useful, though.

From what I can see, the fix to make the file go back to the correct (earlier) spot when going backwards results in it creating a loop when going forwards. The code to do it all is split over 3 routines, which is where the problems lie - there is no useful interaction between their states.

 

[birdman]

I also have versions of findFrame() and findNextPicture() which I've changed a lot to simplify the logic. These seem to work OK (at least in a few tests I've just done) in both directions. Although 64x forward is "slower" than 16x forward.

 

[baz2011uk]

birdman if i can be of any help please let me know i know i dont understand 99% of this but am willing to learn and help

 

[birdman]

birdman if i can be of any help please let me know i know i dont understand 99% of this but am willing to learn and help

Thanks, but what I really need to know is how the incoming offset is being set, and what are valid and useful settings to return.

 

[baz2011uk]

Thanks, but what I really need to know is how the incoming offset is being set, and what are valid and useful settings to return.

see lost me already

 

[birdman]

see lost me already

But the post had its uses.
It's made me think that I ought to look at where the incoming value of the offset is coming from - so I might find out what has happened to get it there....

 

[birdman]

Given that the files in question haven't change in 4.0* I'll start working on that version now...

* well, tstools.cpp did. Two instances of hex constants on one line were lower-cased - there was a third on the same line which is still in upper-case(?!?).

 

[Huevos]

At least it's not mixed case.

 

[birdman]

Given that the files in question haven't change in 4.0* I'll start working on that version now...

Which I'll start by writing a findFrame() which goes to the I-frame in the previous or next GOP, return a valid frame-move count and let the caller decide what to do. The present code isn't guranteed to get out the the current GOP.

PS: I'd remove the big Fix tag from pos #85 if I could. Although the pvrparse.cpp path there is definitely correct and required. I have a test program to show that - it's not dependent on actually playing a movie file to test it.

 

[birdman]

Will be delayed .
At the moment I can't set-up a development environment on a Debian mips system.
There are lots of unresolved symbols when loading enigma2, ad I can't tell whether this is from the switch to gcc5.3 or just something I've missed in the environment. (Since all of the OpenVix libraries get stripped I can't tell which one, if any, has the missing items).

 

[Huevos]

We are all using Ubuntu. No problems building the image or just the E2 binary.

 

[birdman]

We are all using Ubuntu. No problems building the image or just the E2 binary.

How do you just build the enigma2 binary (building the image isn't an issue).
In the image build set-up none of the sources and object files is left around.

Anyway - I've decided that, since I have a plan for the findFrame() code anyway I can flash back to 3.2-037 to test it (I have a saved image of that and of my current 4.003). Then I can set about building automake, make, and gcc5.3 for the OpenVix set-up itself (where I can install all of the dev libraries as-built), and not have to rely on a Debian mips set-up.

 

[Huevos]

How do you just build the enigma2 binary (building the image isn't an issue).

Mostly I just rebuild the image. Only takes about 5 minutes. And then I can just pull the update.

To just build enigma2, first time round you need to build the image. After that you can just build the module. In the example below the locations are according to my setup, and just for reference so you can find the folders:

enigma2 git location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/git
enigma2 binary location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/package/usr/bin/enigma2

cd /home/username/3.4/builds/openvix/developer/vusolo4k
MACHINE=vusolo4k
MACHINEBUILD=vusolo4k
. env.source
bitbake -f -c clean enigma2
bitbake -f -c unpack enigma2

(transfer modified files to "enigma2 git location")

bitbake -c package enigma2

(retrieve enigma2 binary from "enigma2 binary location")...