Posts: 151
Joined: Aug 2013
Reputation:
1
Devices: RPi 2 & HD Homerun Prime (Verizon FiOS service)
OS: OpenELEC 6.0
Applications: Official HDHR Addon
Notes:
- Purchased MPEG-2 license key from raspberrypi.com. Verified that it's activated.
- Hardware acceleration is enabled for OMX and MMAL.
- RPi HDMI out to TV HDMI in
I had a previous issue with stuttering, but that seems to have been resolved after more efficient network schematics.
This isn't a deal breaker issue, but I was wondering if others experience this. Typically, when I start up the HDHR application and stream live TV, I'm about a half to a full second behind what the cable box's stream. If I check back in 24 hours, I might be a full 4-5 seconds behind. A day later, it could be as much as 10 second delay.
What causes this delay, why does it progressively get worse, and is there a way to remedy this?
I have multiple Raspberry Pi 2 devices running on the exact same LAN, with the exact same setup experiencing the same problem. One other issue I notice is even if the RPi's are started simultaneously on the same channel, over time they will lose sync with one another. This likely is caused by the same thing that causes the previously mentioned issue.
Any reasoning as to why this happens and how to fix it?
Love the Pi's, love OpenELEC, love Kodi and the community here!
Posts: 359
Joined: May 2009
Reputation:
8
This may be introduced with the HDHR device as it has to transmit the signal over IP. I have noticed the couple second delay when playing a HDHR stream with my Pi 2 as well as other devices in both the HDHomeRun addon and MythTV. I compared it to a TV hooked up directly to an antenna to confirm.
Someone with a USB tuner may be able to chime in if their is a delay using one of those devices.
Posts: 359
Joined: May 2009
Reputation:
8
Ethernet cable length the exact same?
Posts: 59
Joined: Dec 2012
Reputation:
0
Do you have 'Sync playback to display' ticked? Are both Pis hooked up to the same make and model of TV? I'm wondering if the drift is due to syncing on the TVs themselves.
As someone has said above, the initial out of sync is likely to be the Homerun itself, but just my 2 cents on the other issue.
Posts: 8,966
Joined: Feb 2011
Reputation:
426
Lets do a thought experiment.
Take two raspberry Pi's without network connectiion. Lets say you play "The Dark Knight" on each Pi, playing off sdcard.
The movie is 152 minutes. But where does the playback speed come from?
It depends on the "sync playback to display" option, but it basically depends on the speed of the audio samples being output or the speed of the vsyncs sent to display.
This timing is determined by the crystal oscillator, which on the Pi is 19.2MHz. All computers will have a similar osc which will determine their concept of time.
But an oscillator has a certain accuracy. Typically this is of the order of 100ppm (parts per million) or 0.01%.
0.01% of 152 minutes is 0.9 seconds. So possibly Pi A may finish playing "The Dark Knight" ~1 second earlier than it should, and Pi B may finish ~1 second later than it should.
This effect also means that the Pi's clock (like any computer) will be somewhat wrong at the end of each day (~8 seconds per 24 hours). With an internet connection you can use NTP to sync to a more accurate clock source, but that doesn't feed back to the audio and display clocks which determine playback speed.
Now, playing "The Dark Knight", no one cares about finishing a second early or late after a two and a half hour film.
But for live streams (either PVR or streaming from a live internet source) this can be an issue.
You can have two scenarios. The client may run faster than the server, or the client may run slower than the server.
If the client is slower, then the amount of buffered data increases with time. We may start playback with 2 seconds buffered, but we could have 3 seconds after two and a half hours and 10 seconds buffered after 24 hours. Unless you exceed the allowed amount of buffered data, this probably isn't too critical. You only notice if you compare two clients watching the same stream.
If the client is faster, then the amount of buffered data decreases with time. The 2 seconds of buffered data you start with will gradually decrease until after perhaps 5 hours you now have no buffer. Kodi will probably stutter or buffer for a bit and hopefully the buffered data will increase enough for smooth playback for a while. But this cycle will repeat every few hours.
This is the current behaviour of stable Kodi. I believe Isengard and Jarvis both have this behaviour (at least for many live sources).
However on Kodi master branch, with the VideoPlayer rework things have improved. There is now a mechanism for any stream to report itself as "realtime".
VideoPlayer now tries to manage the amount of data buffered internally.
When the buffer starts to get too low, it slows down playback (by resampling the audio) to allow it to gradually build up.
When the buffer gets too large it speeds up playback (again by resampling audio).
Depending on how tightly the "low" and "high" buffer thresholds are set you can ensure a fixed latency between data sent from server and played out by client. That means with this scheme a number of clients will be more tightly synchronised, as well as avoiding the issue of playback problems when buffered data gets too large or too small.
Posts: 359
Joined: May 2009
Reputation:
8
I just tested my Pi 2 running the HDHomeRun App for 7hrs and 45min against one that just started and they appear to be in sync (the audio was anyway). Both have sync playback to display enabled and are using OMXPlayer (not MMAL).
