Although just one day experience, I really like the scraper_support version; it seems more stable than the current vomp-client version (I think that's because of the segfault conditions Marten debugged); haven't had to reboot once yet...(knock on wood).
I just have two small bugs to report:
1) When displaying a 16:9 screen on 4:3 TV in letterbox mode, the lower black bar is not black but dark blue; the upper black bar is black, as expected.
2) When exiting a recording, and resuming it, the recording starts about 30 seconds later than where it was exited. This is not new behaviour, it also happened on the current (git master) vomp-client.
I guess this has something to do with either the vomp-server or the vomp-client starting at the first i-frame it encounters, but it means all p- and b-frames in between the exiting and the resuming are lost.
IMHO, the correct thing to do would be to jump back to the first I frame and start playing from there; this is the behaviour VDR itself does. It usally means the resume point is a little before the exiting point, but a little "replay" of a recording is less annoying than missing half a minute of the story :(
I have no idea how complex that might be, a quick (but less elegant) fix would be just to rewind 30 seconds after resuming.
Marten, any ideas on this?
Regarding 2), it is supposed to go one GOP back,
, may be changing:
vdr->getNextIFrame(nextiframeNumber, 0, &filePos, &iframeNumber, &iframeLength);
to
vdr->getNextIFrame(max(nextiframeNumber-1,0), 0, &filePos, &iframeNumber, &iframeLength);
in " void Player::restartAtFramePI(ULONG newFrame)" helps. Tell me if it helps.
Regarding 1), this is the gradient in the background, in order to change this, the player would have to set the background to black.
Marten
Very strange, the change doesnt seem to change anything in the behaviour ?!?
/EDIT: restartAtFramePi only gets called when state is switched to S_JUMP_PI , which is not switched when resuming a record to play....
Ok, then it was the wrong one.
setstartframe should then be changed, with a similar logic.
Marten
1) is now changed in git.
Marten
2) is also now changed in git. It goes back to last iframe.
The problem is you never know how long you have to go back, since the resume point is determined on the server side.
That means as resuming point always the last frame, that was streamed to the raspberry pi is taken.
Since we have some buffering, that is always inaccurate.
Marten