Tvheadend

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.

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)?

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...?

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?

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.

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?

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).

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

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.

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

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

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?

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...).

LoL i didn't get a single word of what you said 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

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.

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

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.

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.

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

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