Comments (8)
There is both a short and long explanation for this one (of course!)
The SHORT version is: this is a Kodi/ffmpeg concern and there really isn't anything I can do about it in the PVR client.
The LONG version is (caution: will be replete with inaccuracies, hopefully the general gist is accurate enough):
Back in ye olden days TV signals were broadcast using multiple frequencies for the audio and video and they were sent at the same time and in sync. The tuner/receiver would receive both signals simultaneously and convert them to output realtime, so there was never really an issue with synchronization.
Nowadays we have digital video, of course, and it's delivered via a 'multiplexed' stream of bits. There is only one series of 1s and 0s to go around, so what they do is intersperse the video data stream and audio data stream together something like this:
VVVVVAAVVVVVVAAVVVVVAAVVVVVAAVVVVVAA
The receiver/decoder takes the multiplexed data and breaks it apart into separate Video and Audio streams, this is called demultiplexing or 'demuxing' for short.
As part of the stream data, time points (the pts you see mentioned in the Kodi thread) are provided so that the decoder can synchronize the video and audio. An ideal decoder would be able to keep everything in sync all the time for you, but as always nothing is ever ideal :)
What I think is happening here is that the synchronization points aren't included constantly in the data (I think, anyway), and that when you switch to a new stream or seek on the same stream the decoder (ffmpeg in this case) is making a mistake. It may be from a lack of this pts information or it could be a defect in the implementation. When enough information is present, it can resync everything.
My best guess here is that Kodi/ffmpeg is estimating what the sync should be in order to start playback as quickly as possible and the estimation is off. If it's only happening when channels are switched, it could even just be a small glitch in how Kodi is (re)initializing ffmpeg when the stream switches.
Unfortunately for us, all the PVR client does is take the raw multiplexed stream data from the tuner and hands it off to Kodi; all the demultiplexing and synchronization happens outside of the PVR client, so currently there isn't going to be anything I can specifically do. It would be possible to use a custom demuxer rather than relying on Kodi, but that's extremely ambitious and is very likely to be riddled with bugs, the Kodi guys and gals have been doing this a long time now I have little to no confidence I could do something better than what they have.
I think the best bet here is to reply to the thread on Kodi's forums and ensure the problem maintains visibility. I think they upgraded ffmpeg in Kodi 17.4, so it really may just be something simple they can tweak for Kodi 17.5 or 18.0.
Sorry if my details are inaccurate here and there, I didn't want to just drop a "sorry not my problem" on you, I really hate when people do that!!
from pvr.hdhomerundvr.
Ok, thanks for the explanation. I noticed that unofficial pvr plugin included with kodi: https://github.com/kodi-pvr/pvr.hdhomerun does not have this problem.
from pvr.hdhomerundvr.
The addon that comes with Kodi accesses the streams directly from the Tuner device(s) as opposed to the DVR engine. The streams from the tuners are lacking a series of padding bytes that the DVR engine inserts, which likely explains the difference -- Kodi needs to read more data before it finds the sync info.
You can change the setting on this PVR "Stream Live TV channels directly from Tuner device(s)" (https://github.com/djp952/pvr.hdhomerundvr/wiki/Options#stream-live-tv-channels-directly-from-tuner-devices-version-105) to get the same behavior to test that out. Note that if you enable that option, you lose timeshifting (seek) capabilities since the buffering is all done on the DVR engine.
It makes sense that you'd have more luck with the tuner streams than the DVR streams with a problem like this, but sadly there still isn't much of anything I can do to manipulate the stream to make it go away. One (remote) possibility would be to delay sending any data to Kodi at all until the necessary sync information has been detected, but if you delay too long Kodi assumes the stream is bad and gives up completely. I also really wouldn't know what to look for, at least not right now. If this gets really bad with no hope in sight for a Kodi-side fix, I'm game to try.
from pvr.hdhomerundvr.
Marking this one as closed due to inaction on my part. If the explanation was unsatisfactory or you have additional concerns that I might be able to help with, please don't hesitate to open a new one! I disappeared for a couple months on you guys, but I'm back now :)
from pvr.hdhomerundvr.
Changing the "Stream Live TV channels directly from Tuner device(s)" setting did solve the issue. Would it be possible for the plugin to disable timeshifting when this option is selected, since timeshifting doesn't work when it is selected and causes the stream to stop?
from pvr.hdhomerundvr.
Funny you should ask! It does disable timeshifting when tuner-direct streaming is enabled on Jarvis and Leia, but not Krypton :) There is a bug in Krypton that also disables Pause, which technically still works since Kodi buffers internally.
The irony here is that I fixed that bug in Kodi and submitted a patch to them months ago. They accepted the patch but put it in Leia rather than Krypton. It was their call to make, I assume the problem wasn't deemed widespread enough to deal with the testing required for what I think at the time was v17.4.
I can fix that in Krypton very easily, it's a matter of choosing between allowing pause or not. At the time, the folks on the SD board chose to keep pause working and just not press the FF/RW buttons :)
There are like a billion options in there these days, perhaps one more just for Krypton won't hurt then we can have it both ways? Would that be OK?
from pvr.hdhomerundvr.
from pvr.hdhomerundvr.
Actually, the last advanced option: "Disable reporting of real-time MPEG-TS streams" has about the same effect as streaming directly from the tuner and it doesn't break timeshifting. So, that is an acceptable solution for me. You don't need to make an option for me then.
from pvr.hdhomerundvr.
Related Issues (20)
- Remove 'Disable reporting of active Live TV tuner signal status' setting HOT 1
- Add ability to specify an HTTP proxy server to route all discovery operations through HOT 3
- HTTP device discovery will abort at first failure HOT 1
- Block trying to set up a recording rule for a channel that is only available on legacy devices HOT 2
- Create a wiki page describing how legacy devices are supported HOT 1
- Manually triggering a discovery event should log the entry/exit points HOT 1
- Update build environment to use Xcode 11.3.1 / Mac OS SDK 10.15 HOT 1
- Consider switch to wolfssl from OpenSSL HOT 3
- Update SQLite to version 3.38.0 HOT 2
- Update libcurl to 7.82.0 HOT 1
- Update libxml2 to 2.9.13 HOT 1
- Rework the update repository to also allow for prior versions HOT 1
- Canonicalize all file system paths prior to using them HOT 1
- Libelec on Raspberry Pi 4 HOT 2
- Channel Guide Missing on Fire TV Cube HOT 2
- Add ability to specify an HDHR device by fixed IP address
- Add ability to specify (fixed) IP address of HDHR appliance(s) to better integrate with VPNs HOT 4
- Upgrade to LibreELEC RPI 11.0 7-23 Nightly causes boot loop with pvr.hdhomerundvr enabled HOT 3
- Kodi Nexus 9-17 Nightly upgrade causes a compatibility issue with pvr.hdhomerundvr HOT 7
- Base Function Questions HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pvr.hdhomerundvr.