10 replies to this topic

[linus]

Hello,

I have got a problem on my openPli 9.0 (upgraded to lattest so correction here).
 

Context:
Vu+ solo SE V2 updated to the lattest stable version (update done to day)
Record TNT T2 (1080P)

 

When i play record and fast forward, or back forward a time (for exemple to jump the publicity) when i play back, subtitle does not come again. Nothing appear. On my previous rom OpenATV 5.1, it alwas come back after something like 2s after the ui disapear.
But here, If i jump to an epg marker that delimit the start of new program, it come back again.
If i stop, then play again to come back in the record and enable subtitle, of course it works.

 

Is there something i could do to solve this problem?
Thank's

[littlesat]

I cannot confirm it here with subtitles… And when you use step skip instead fast forward and backward?

Edited by littlesat, Today, 11:48.

[linus]

Does "step skip" is not the case i wrote there: "If i jump to an epg marker that delimit the start of new program, it come back again." with the key > on my remote ?
I did not find other key on my remote to "jump". cross right key does the same then fastforward button.

Edited by linus, Today, 12:01.

[linus]

Ok, i found the jump key, it's 1/3 4/5 7/9.
So if i use this key, it works immediatly, so the problem is just with fast and back forward.

[40H3X]

Just don't use them/ only use skip instead , please read https://wiki.openpli...weaks#Skip_time

[linus]

Yep i found that and already found the key as written before, but that does not explain why it was perfectly working before in an old openAtv and not in openPli 9.0.

If the bug could be corrected it would be better.

 

Just to explain why: the vu+ are used my by parents, so forward/backward is a notion that exist since a lot of time, even if they could understand jump key, you could not say that push on 6/9 key is something intuitive and remember every time how much time jump key does is not something easy for somebody that are more then 70 year old.

And is somebody external come and watch a record, samething, you should explain again where as forward/backward is internatial and have been exist since a lot of time.

Edited by linus, Today, 15:32.

[WanWizard]

You still haven't understood what I have been telling you?

 

You are making assumptions that are not correct: you can not compare the behaviour of driver A with stream X, which driver B and stream Y, and then say "the first combination used to work, so the second must work now", it is simply not true.

 

And I doubt there is a box that has a working fast-forward / fast reverse, given the fact you're not dealing with an analog tape you can speed up or reverse, you're dealing with a compressed MPEG data in a stream with 188 byte packages containing different frame types.

 

You can only reliably jump from I-frame to I-frame, and whether or not you have them, how many, and how they are spaced in the stream, depends on the settings of the MPEG compressor at the source. This is what the jump keys do.

 

Fast forward / Reverse jump to arbitrary locations in the stream, landing on most likely not an I-frame, which means a very complete operation must follow to construct something of an image at that point (apart from I-frames, MPEG frames are delta's on the previous frame, so not a complete picture).

 

Most drivers are not very good at this complex operation, which is made worse if there is corruption in the MPEG stream, which could mean assumptions the drivers make about the stream may not be correct.

 

For your parents, you could update the keymap, and map " <<  " to the 1 key, and " >> " to the 3 key? Downside is that it is only one jump, it doesn't keep jumping until you press play again. I understand that jumping is something new to learn, but it is the technology that is limiting it, not the software.

[WanWizard]

p.s. nobody is stopping you from downloading drivers from 2017 and installing those into a current image, that should work fine ( apart from the fact you'll miss any bug fixes since 2017, which might introduce other issues ).

 

These are all the drivers for the Solo SE  ( this is what we're talking about, yes? ) ever released:

[root@openpli-dist vuplus]# ls -l vuplus-dvb-modules-vusolose-3.13.5-201*
-rw-r--r--. 1 1002 1002 4034235 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20141201.tar.gz
-rw-r--r--. 1 1002 1002 4034508 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20141231.tar.gz
-rw-r--r--. 1 1002 1002 4035400 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20150109.tar.gz
-rw-r--r--. 1 1002 1002 4150432 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20150317.tar.gz
-rw-r--r--. 1 1002 1002 4152722 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20150403.tar.gz
-rw-r--r--. 1 1002 1002 4154663 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20150511.tar.gz
-rw-r--r--. 1 1002 1002 4169316 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20150623.tar.gz
-rw-r--r--. 1 1002 1002 4171552 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20151117.tar.gz
-rw-r--r--. 1 1002 1002 4171491 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20151201.tar.gz
-rw-r--r--. 1 1002 1002 4429534 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20161228.tar.gz
-rw-r--r--. 1 1002 1002 4431931 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20170522.tar.gz
-rw-r--r--. 1 1002 1002 4431935 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20170822.tar.gz
-rw-r--r--. 1 1002 1002 4432113 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20171107.tar.gz
-rw-r--r--. 1 1002 1002 4437267 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20171121.tar.gz
-rw-r--r--. 1 1002 1002 4437347 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20171127.tar.gz
-rw-r--r--. 1 1002 1002 4437170 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20171204.tar.gz
-rw-r--r--. 1 1002 1002 4525496 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20180220.tar.gz
-rw-r--r--. 1 1002 1002 4529502 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20180319.tar.gz
-rw-r--r--. 1 1002 1002 4530286 Oct 28 18:47 vuplus-dvb-modules-vusolose-3.13.5-20190429.tar.gz

You can find the version you're using on the box, menu - information - about.

[linus]

Just to be sure we are talking on the same thing. I am not talking about the previous pb i was talking in the over thread. (in the corrupted file).

Here i am just talking about the lost of the subtitle when playing a record and if you do a fast forward/back . No problem for audio or video forward/back. Just the subtitle disappear, and it's the case in all the record.
if you pause play, it change nothing, but If i just make a "jump" in the video ( every jump key ) without exit the video, it immediately come back.
For you it's related to driver?

 

"you can not compare the behavior of driver A with stream X, which driver B and stream Y"
You do not understand me or i do not explain well.
I took the record i have done with the OpenPli 9.0, play it with OpenAtv 5.1 and... And subtitle works perfectly.
So the sentense is:

I compare the behaviour of driver "A with a record X" with "driver B and same record X"

But i have try the opposite: play a record made with openAtv 5.1 on OpenPli 9.0, and the result is the same, it works perfectly on openAtv 5.1 where as i lost the subtitle when fast forward on openPli 9.0.

 

If you are totally sure that it's a driver problem and could not be other things (like a rendering bug/problem or video playing in enigma or the skin used) then i have got my answer and as you said i could test older driver to see if it' change.
But if it's not related to driver/hardware, i would have found a good idea to solve a problem that was not here before bug.

 

 

For your parents, you could update the keymap, and map " <<  " to the 1 key, and " >> " to the 3 key? Downside is that it is only one jump, it doesn't keep jumping until you press play again. I understand that jumping is something new to learn, but it is the technology that is limiting it, not the software.

 

I try to take a look, but on the hotkey did not find any possibility to map a key "jump fonction" if i am not wrong.
In openATV i could use "long press" on right/left to move in the video time so jump to a position (that's easy to understand where you are and what you are doing), but here i do not find this functionality or mapping possibility, it could have been a solution to solve the problem too but if i am not wrong i do not find this possibility in openPli 9.0.

 

 

 

 

And I doubt there is a box that has a working fast-forward / fast reverse, given the fact you're not dealing with an analog tape you can speed up or reverse, you're dealing with a compressed MPEG data in a stream with 188 byte packages containing different frame types.

Just for information, as i said, it was the case for OpenAtv 5.1 on this hardware, but it's the case of a lot of commercial TNT player/sat player that could record in TS (even if they are more limited, or buggy in some over point) and of course, it's the case of a lot of video player (like mpv/vlc/mplayer) that could play exactly this record with subtitle and fast forward with no problem so even if it's complicated and could be source of problem it seems it's not impossible.
 

[WanWizard]

Restoring old drivers on a 9.0-release image is not that complex ( assuming you can handle a linux commandline ), so it can easily be tested if it is a regression in the drivers or not.

 

As to subtitles, whether they are TXT or DVB image subtitles, they are seperate "tracks" in the MPEG stream ( packets with a seperate ID, multiplexed into the MPEG stream ). They should have a timing track with them (like the old timing track on a movie reel ), which is used to synchronize video and subs. But some providers make a mess of things. If the timing track is missing or wrong, Enigma will try to show the subtitles when they are read from the stream, without buffering and timing.

 

From a technical point of view, fast forward or reverse is implemented in the drivers ( and we don't have the source, so no idea how ), but a jump is implemented in Enigma, it essentially stops the playback, does a seek in the video stream looking for the next I-frame the defined number of seconds in the future, and then restarts playback of the stream, not from byte 0 of the file, but from the point found. Which makes it a lot more reliable, as it is essentially identical to starting the playback of a recording.

 

As explained before, how the stream is encoded plays a massive part in if and how this works. If for example the compression is so heavy that there is only an I-frame every 5 minutes, a 15sec jump will actually jump 5 minutes forward, and also the stream is much more susceptible to corruption ( which causes blocks or parts of the video standing still ) because it needs an I-frame to re-assemble a complile frame from all delta frames.

 

I can imagine ( but not prove ) that drivers that were designed on the assumption that there are I-frames every few seconds may run into conditions not expected by the developers when I-frames are much more spaced out...

[linus]

Thank's for the explanation and play/pause are in driver too like fast forward or reverse?

 

No problem for cmd line. It's more time that is needed.
Do you think that i could try the modern driver in the old openATV to see if the fast/back pb appear?

If i got time/Possibility i will try to test OpenATV 7.4 or other recent rom with this same record to see if i got the same pb with subtitle to see if all the rom got the problem or not.

 

I did not found a way to replace the >> and << with "jump" function. :/

Edited by linus, Today, 19:04.