This repository has been archived by the owner on Apr 15, 2023. It is now read-only.
Porting buffer fix from Adam's pvt.tvh https://github.com/adamsutton/xbm... #278
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is an attempt to fix several limitations within pvr.hts, and rather than try and rework broken code I've decided to start from scratch. Some basic boiler plate has been copied and clearly the code isn't miles different (since its trying to achieve the same basic goals) but it is a rewrite.
some warnings are still in place since I do intend to use the variables when I implement the functions. So they will serve as reminders.
…buffer.
I (and others) had completely failed to notice that the default buffer size
for the SyncedBuffer object that pvr.{hts,tvh} was using is ridiculously small
and thus could result in lost data (worse there was no error output - doh).
I have increased to unlimited length, its implicitly bounded by other things
and there is little point bounding it. If it were to fill indefinitely then
something would have to be seriously wrong and the system would probably
eventually crash for other reasons!
This appears to fix timeshift issues, I wonder whether it will fix other things
as well!
XBMC doesn't even use this API method, it's one of those many things that no one has ever bothered to clean up
This way XBMC will handle changes in aspect ratio (ie. 16:9 <-> 4:3). Should fix the issue reported here: http://forum.xbmc.org/showthread.php?tid=170485
What it means is we convert tvheadend's notion of "seconds shifted" to an absolute timestamp. This fixes two issues. The first one is that if you pause a live stream at e.g. 10:00 program time (ie. 10 minutes after it has started), wait for 30 seconds, unpause and then rewind 30 seconds, XBMC would display the current time as 11:00 when in fact it should be 10:00 again (since we rewinded the buffer to the beginning). The other issue is more of a new feature. Now when you pause a live stream long enough XBMC will display the shifted position along with the live position in the seek bar, so you know roughly where in the shift you are.
In fact we got a response but it was invalid or had no meaning (I'm not totally sure what a time of -1 means)
Pulling tvh addon
…bmc-pvr-addons Merging Time Shift improvements
|
you've used your master branch and added more code to it. please clean up the PR |
|
Please open a new ticket with the fix if you're still interested in fixing the issue, as it can't be pulled like this |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fix was ported and tested against the master branch.
Issue addressed:
Pixelation and artifacts are extremely visible after resume from pause, adding debug statements, we were able to track the packets sent by tvheadend and identify packets received by the addon but not read by the demuxer. Adam quickly identified an issue with the buffer that can lead to this behavior.
Note:
This fix is a huge improvement to the current code, however there is still random/micro pixelation, the root has not been identified yet, but it seems to be deep down into either xbmc or ffmpeg.
20:57:56 T:139716527634176 ERROR: ffmpeg[49FFB700]: [h264] mmco: unref short failure
20:57:56 T:139716527634176 ERROR: Previous line repeats 1 times.
20:57:56 T:139716527634176 ERROR: ffmpeg[49FFB700]: [h264] number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one
20:57:56 T:139716527634176 ERROR: ffmpeg[49FFB700]: [h264] mmco: unref short failure
20:57:56 T:139716527634176 ERROR: Previous line repeats 1 times.
20:57:56 T:139716527634176 ERROR: ffmpeg[49FFB700]: [h264] number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one