Project

General

Profile

TVHeadend buffering problems

Added by lord slash about 10 years ago

Hi all, I successfully configured a couple of days ago a DVB-T Stick on a Raspberry PI model B running Raspbian Wheezy and TVHeadend 3.4: muxes added, channels found, tried it with VLC, my Android smartphone and XBMC and everything seemed to work fine.

What i noticed is that from time to time, the video stream is jerky and seems to have buffering issues on both XBMC (which is running on another Raspberry Pi with Openelec) and VLC (on my windows laptop).
I have to underline that the TVHeadend Backend is running in Italy on my parents' home, while my Frontend (XBMC or VLC) are here in Berlin, Germany, where I live.
I thought that the connection could have been too slow, but the stream seems to need between 4 and 5Mbit as upload speed so i run a speed test on my backend (Italy) and i have more than 9MBit as upload speed available:

pi@raspberrypi ~ $ ./speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Fastweb (2.234.xxx.xxx)...
Selecting best server based on latency...
Hosted by Hynet s r l (Vicenza) [30.67 km]: 59.422 ms
Testing download speed........................................
Download: 24.20 Mbits/s
Testing upload speed..................................................
Upload: 9.14 Mbits/s

I run then a speedtest on my frontend connection (in Germany) and the result is 28ms ping, 14MBit upload speed and 1Mbit upload speed.

The weird thing is that sometimes the stream works flawless and sometimes it's really unwatchable (2 seconds of buffering for a second or video). I tried with several channels and I saw always the same behavior
I hope I explained my problem clearly enough and that someone will be able to help me!
Thanks in advance


Replies (20)

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Immediate thoughts...

1. Italian upload speed is to the exchange/DSLAM/ATM PVC. It's not all the way, so congestion could happen en route.

2. Have you tried recording a 'buffering' programme?

3. Does it buffer if you play it locally (in IT or DE) - if so, it's a signal issue.

4. Does it buffer if you play back the recording at much the same time?

5. Does it buffer if you play it back the next morning?

6. Is there any other way of monitoring the source while you watch? I'm thinking of the recording... if you get buffering but could check a local recording at the same point then you'd determine a lot.

My suspicion would be contention on the backhaul, possibly at a particular time. If you get a good signal sometimes, then the Pis are up to the challenge (unless there's another process that's taking RAM, CPU or disc I/O). So the variables are broadly reception and uplink.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

unfortunately i can't test the local play (I am not in Italy right now), but i will try to record a program and see it works afterwords.. What i see is through the TVHeadend status page is that the average signal strength is around 30% (which could be a bit poor).
But what i find interesting is that I get the same behavior when I play an HD channel, which uses around 8MBit, and a normal channel (around 4MBit)..
By the way, on my backend PI there's only the TVHeadend server running, so I guess no particular CPU/RAM usage is affected (here's the top output:
@
top - 22:04:01 up 1:31, 1 user, load average: 0.21, 0.13, 0.14
Tasks: 61 total, 1 running, 60 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.0 us, 4.0 sy, 0.0 ni, 90.6 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 447864 total, 431416 used, 16448 free, 25312 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 352872 cached

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
1951 hts 20 0 178m 16m 1648 S 12.8 3.9 2:59.15 tvheadend
5113 pi 20 0 4672 1456 1040 R 0.7 0.3 0:00.79 top
39 root 20 0 0 0 0 S 0.3 0.0 0:20.53 mmcqd/0
2164 pi 20 0 9392 1684 1052 S 0.3 0.4 0:01.71 sshd
1 root 20 0 2148 720 616 S 0.0 0.2 0:01.92 init
......

@

Is it possible that my ping is too high (50ms)?

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Can't comment on that - 50ms for several hundred km doesn't sound terrible, but if you run on a LAN it's < 1ms. Latency shouldn't be a huge problem... jitter would be more of a threat, I'd expect.

You'd need to check the ping time (a) when it's working, and (b) when it's not, so you can see if there's any noticeable difference. And ping a lot of packets so you get the spread.

Signal strength ... it's adapter-dependent, unfortunately, so 30% may be awful (it does sounds that way - I never get < 50%). Again, if it's a bad signal then a local recording should show artefacts at the same time.

You could also try a different revision of tvh, see if that shows any different behaviour...?

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

I tried to view some channels this morning and it works perfectly.. I have a very similar ping time (50ms) and upload speed available (9,44MBit). Is there a way to measure the Jitter between my backend and my frontend PIs? I tried to record a tvshow yesterday night and it is also fine..
Moreover the problems i was noticing were typical buffering problems (video played-video automatically paused-the VLC time bar shows a yellow loading bar increasing for a couple of seconds till it gets full-video plays again), but as I said the available bandwidth seems to be enough..
Interesting is that i noticed the buffering problems in the evening between 21 and 23, so at a typical high internet usage hours.. Is it possible that the route is congested? Is there a way to test it?

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

The only ways I know to measure variation in latency or upload speed is to repeatedly perform the same task and see how long it takes. There are tools to do this (e.g. SmokePing or iperf, from a quick Google for 'measure jitter linux') or you can do it by hand.

You could have a ping running constantly in the background, you could repeatedly ftp or otherwise copy a file across the link, you could run speedtest from both ends. Remember that congestion could be anywhere on the link, and it's dependent on the route those packets happen to be taking - Italy to Germany might go via London or Amsterdam, after all.

The next question would be whether there's anything you can do about it. Unless there's some form of end-to-end QoS, I'm not really sure what you could do beyond transcode the stream to something less latency-sensitive.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

Is transcoding supported by Openelec XBMC Live TV?
As i wrote in my first post, i run a speed test while the problem was showing up and i had 9Mbit in upload and 14MBit in download available (so theoretically more than enough, but it's possible that the speedtest is developed IT-IT and DE-DE, while my problem is the route IT-DE.
I think i will transfer a 100Mb file between the two PIs at different time (or better, i will try the transfer when the problem shows up again).. Anyway I thought it was possible to increase the buffer size in XBMC or simply to pause the stream to "let it buffer a little", but both options seem not to be possible.. am I right?

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Transcoding isn't directly supported, but you could use VLC as a proxy. Clumsy, and not ideal on a Pi - realtime transcoding of 1080p might be a challenge :)

Speed test typically tests to a local server, so you're looking at each end of the conversation and not end-to-end. If you run a tracert from one client to the other you'd get a better idea of where the traffic is going on its long journey past the Alps.

Buffer size in XBMC... yes, you can tune the buffer, although PVR is different from 'normal' videos. I found this thread which would be worth investigating:

http://forum.xbmc.org/showthread.php?tid=159142

Regarding 'pausing a little' - not on 3.4, I suspect. If you move to master (3.9.x), and swap pvr.hts for pvr.tvh, then timeshift will work much better (although not yet perfectly) and that might help. That said, swapping either the tvheadend process or the PVR addon isn't a trivial exercise on OpenElec, although it's doable. There are various threads on the XBMC/Kodi forum that may help if you wanted to give that a try.

The other thought ... if, instead of streaming, you record it locally, and have a mapping from your local client to the remote one, then you can play the file as if it were any other recording - including pause. Basically, bypass Live TV completely on the DE end. Ugly, and not really for long-term use, but another test... I know you'll get problems when you reach what XBMC expects to be the end of the file, for example (i.e. the size it was when you first started playing it, even if it's getting bigger all the time).

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

I made some point-to-point speed tests yesterday evening (the problem showed up again): i transfered a file (200MB) between the two PIs and the speed was 250KB/s, while when i transfered the same file this morning the speed was 1100KB/s (which means that there is actually a congestion in the route between the to PIs in the evening). Question is what to do against it :)

I will try to play around with the buffer sizes in advancedsettings.xml on my xbmc, thanks for the link!
And regarding the TVheadend versions, i didn't get what you mean with "swap pvr.hts for pvr.tvh". I understand i have to install a newer version (3.9.x), should i compile it or is there a raspberry pi precompiled version that i can get with apt-get?

I will keep the last option (recording-playing meanwhile i record) as a "last option" cause i find it a bit ugly :D

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

At least you know where the problem lies...

The standard Live TV addon is pvr.hts - adamsutton and negge rewrote it as pvr.tvh, although it's not yet officially included with XBMC. So there's some manual compilation needed to produce a new zip file and load it into OpenElec (unless someone has a Pi version already wrapped up). Likewise for 3.9.x, that need compiling into an OE addon unless you can find one pre-built.

There are threads over on xbmc.org, I'd suggest you search around there. You're not the first to want to try the different options, although I don't know if you'll easily find something that's simple to install. I'll keep my eyes open for you.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

Hold on, why should i compile TVHeadend 3.9.x into an OpenElec addon when my TVHeadend (backend) is now running on a Raspbian?

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

D'oh - sorry, my idiocy - no, they're clearly separate. Backend can be standalone and is independent of the addon.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

good so if i understood right i could try to compile/install on openelec this pvr.tvh PVR (don't know yet how but i will find out), and on my raspbian the TVHeadend 3.9.x (by the way, in the APT repository there are Stable/Beta/Unstable, should i try first with one of them or should i just get the source code from github and then configure/make it? sorry for the lame question :P)

And what i would win is a proper timeshift on XBMC, which would give me the possibility to pause the stream, buffer it a bit, and then play it again..right?

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

That's the plan... timeshift is still a work-in-progress, so there will be some issues, but it should broadly work for pause-buffer-and-play.

As for the versions in Unstable... pass, I'm afraid. You'd need to check dpkg (apt-cache policy, I think) to see what options it presents from those PPAs to see if it's in any way current - building your own is easy enough in most instances, though (famous last words as we now find the dependencies aren't met on Raspbian somewhere along the road...).

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

LoL i didn't get a single word of what you said :D dpkg is used to install/deinstall packages, right? What is PPA? How would i install this 3.9.x version? I think i will try to compile the github version! Sorry if i'm so noob and thanks again for your help :)

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Sorry :)

PPA = repository. Each repository has different packages in it, so you'd need to look at the specific unstable tvh you have defined. It seems like it holds nightlies for Wheezy, but I've no idea if it's Pi-suitable (armhf?). If not, you'll need to compile.

dpkg = used to install packages, it's part of the apt framework. It gets called to install a .deb (package) file when you do a sudo-apt get install <package> or a sudo dpkg -I <file>. So, if you just downloaded a .deb file from 'Builds', above, then this is how you could install it if you're desperate ... (and if you were on an Intel system...)

apt-cache policy = will query all defined repositories to tell you what's available. That's the command-line way to test versus going directly to the repository as I just did.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

great, i edited my /etc/apt/sources.list from deb http://apt.tvheadend.org/stable wheezy main to deb http://apt.tvheadend.org/unstable wheezy main, then apt-get update and apt-get install tvheadend and now i have tvheadend 3.9.1743 ;) i will start to look for the pvr.tvh for openelec and keep you updated! Thanks meanwhile ;)

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Bear in mind that you're now on automated builds of whatever gets pushed to the master branch. If someone breaks it... then your next apt-get upgrade will install a broken version. Your home is at risk, your children may vanish, your kittens may explode, etc., etc.

You'll also potentially get an update with every new code change (depending on if the automated build kicks in). Keep an eye on that, you may choose to manually decline updates if it's working for you.

RE: TVHeadend buffering problems - Added by Prof Yaffle about 10 years ago

Odd - I received an email notification of a reply to this thread, but can't see it. Maybe time will catch up...

Make sure you've enabled timeshift on the backend: Configuration -> Recording -> Timeshift. Restart XBMC.

RE: TVHeadend buffering problems - Added by lord slash about 10 years ago

Yea I actually realized that even though i had TVHeadend 3.9.1743 and pvr.tvh 0.9.3 (last version is 0.9.4 but i didn't find a compiled version for RPI yet and i don't really know how to compile it myself on openelec - shame on me), pause button was still not available during the streaming. I then found out that i actually had to enable it on TVHeadend and now the button is there and i can pause the video.
Weird thing is that it actually doesn't really work: let's say I pause for a 50 seconds, then i push play and I'm able to see the 50 seconds i "buffered", but then the stream freezes... I wonder if I should enable "on demand", or if I should explicitly set a Storage Path or play around with some other setting.. do you have suggestions? thanks ;)

RE: TVHeadend buffering problems - Added by Arshvinder Singh Sehmi about 10 years ago

Hi Team,

Is there any work around of this issue:

1) Let's say I pause for a 5 seconds, then i push play and I'm able to see the 5 seconds I "buffered", but then the stream freezes.

2) I am using XMBC in a location LAN, and I am using TVH 3.9.X, and I am having streaming issues. Like after a successful streaming of 15 - 20 minutes in the beginning. The XBMC will take a pause of 3 - 4 seconds, and loads the buffer, and then continue playing the stream.

Any suggestions to overcome this issue!

Regards,
ErSehmi

    (1-20/20)