Tvheadend

Hi,

Just as a check: Did you test XBMC and VLC on the same machine, both with a wired connection? (otherwise, it might be some bandwidth or other clientsystem-specific issue).
(I didnt try totem, but VLC works fine ...).

Alex.

I have no problem playing tvheadend recordings in VLC - the only issue I've noticed is that the files start at a timecode of 00:30 in many applications (VLC < 2, XBMC, mkvmerge GUI) which can confuse if you're chopping things up. But they decode fine, complete with umpteen audio streams, subtitles, et al.

Copied the file locally to rule out bandwidth issues.

Xbmc plays the file fine.

VLC :-

main warning: PTS is out of range (29113), dropping buffer
main warning: computed PTS is out of range (8285164), clearing out
main warning: PTS is out of range (5164), dropping buffer
main warning: computed PTS is out of range (8285216), clearing out
main warning: PTS is out of range (-18784), dropping buffer
main warning: computed PTS is out of range (8285268), clearing out
pulse debug: deferring start (66160 us)
main warning: picture is too late to be displayed (missing 187 ms)
main warning: picture is too late to be displayed (missing 147 ms)
main warning: picture is too late to be displayed (missing 107 ms)
main warning: picture is too late to be displayed (missing 67 ms)
main warning: picture is too late to be displayed (missing 27 ms)
pulse debug: starting deferred
pulse debug: suspended
pulse debug: started
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: listing sink alsa_output.pci-0000_00_1b.0.analog-stereo (1): Built-in Audio Analogue Stereo
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse debug: missing latency from input
pulse warning: underflow
pulse debug: listing sink alsa_output.pci-0000_00_1b.0.analog-stereo (1): Built-in Audio Analogue Stereo
main warning: computed PTS is out of range (952765), clearing out
main warning: PTS is out of range (952765), dropping buffer
main warning: computed PTS is out of range (952881), clearing out
main warning: PTS is out of range (928881), dropping buffer
main warning: computed PTS is out of range (952925), clearing out
main warning: PTS is out of range (904925), dropping buffer
main warning: computed PTS is out of range (952969), clearing out
main warning: PTS is out of range (880969), dropping buffer
main warning: computed PTS is out of range (953013), clearing out
main warning: PTS is out of range (857013), dropping buffer
main warning: computed PTS is out of range (953223), clearing out
main warning: PTS is out of range (833223), dropping buffer
main warning: computed PTS is out of range (953316), clearing out
main warning: PTS is out of range (809316), dropping buffer
main warning: computed PTS is out of range (953384), clearing out
main warning: PTS is out of range (785384), dropping buffer
main warning: computed PTS is out of range (953450), clearing out
main warning: PTS is out of range (761450), dropping buffer
main warning: computed PTS is out of range (953517), clearing out
main warning: PTS is out of range (737517), dropping buffer
main warning: computed PTS is out of range (953583), clearing out
main warning: PTS is out of range (713583), dropping buffer
main warning: computed PTS is out of range (953649), clearing out
main warning: PTS is out of range (689649), dropping buffer
main warning: computed PTS is out of range (953715), clearing out
main warning: PTS is out of range (665715), dropping buffer
main warning: computed PTS is out of range (953782), clearing out
main warning: PTS is out of range (641782), dropping buffer
main warning: computed PTS is out of range (953848), clearing out
main warning: PTS is out of range (617848), dropping buffer
main warning: computed PTS is out of range (953913), clearing out
main warning: PTS is out of range (593913), dropping buffer
main warning: computed PTS is out of range (953978), clearing out
main warning: PTS is out of range (569978), dropping buffer
main warning: computed PTS is out of range (954032), clearing out
main warning: PTS is out of range (546032), dropping buffer
main warning: computed PTS is out of range (954086), clearing out
main warning: PTS is out of range (522086), dropping buffer
main warning: computed PTS is out of range (954139), clearing out
main warning: PTS is out of range (498139), dropping buffer
main warning: picture is too late to be displayed (missing 709 ms)
main warning: picture is too late to be displayed (missing 669 ms)
main warning: picture is too late to be displayed (missing 629 ms)
main warning: picture is too late to be displayed (missing 589 ms)
main warning: picture is too late to be displayed (missing 549 ms)
main warning: computed PTS is out of range (1792764), clearing out
main warning: PTS is out of range (1312764), dropping buffer
main warning: computed PTS is out of range (1794134), clearing out
main warning: PTS is out of range (1290134), dropping buffer
main warning: computed PTS is out of range (1794180), clearing out

Might be worth sticking this in the issue handler and attach a short sample recording, I'll see if someone can take a look at it.

Adam

Could someone test this please.

VLC cant play it on my computer, but xbmc fine.

http://dl.dropbox.com/u/31423731/tvhtest.mkv

Thanks

Nope, can't play it in VLC - it pauses, stutters, and the timeline indicator seems to have a mind of its own. While this laptop isn't a beast, it should cope with this file without a sweat (i5, Win7-64, VLC 2.0.2) - it's only SD MPEG-2, after all!

Are you recording locally, or recording to a filesystem over a network link, I wonder?

Observation 1: I quickly re-encoded it into H.264 HP with Handbrake, and it plays perfectly. So the file is complete and clearly contains all the information it needs. I would therefore suggest it's something to do with either container or encoding.

Observation 2: a quick ffmpeg re-wrap (ffmpeg -i tvhtest.mkv -acodec copy -vcodec copy -f mp4 tvheadtest.mp4) and the resultant file plays fine as well - so it's not the elemental streams, they're fine.

I wonder if there's a clock/timing issue, or a cacheing issue - perhaps a default in the underlying ffmpeg code, perhaps how it's been incorporated into VLC and XBMC...

EDIT:

Observation 3: In VLC, Tools -> Preferences -> All -> Input/Codecs, scroll to File Caching (ms) and increase to 2000 and it plays fine. So it may be a buffer over-run of some kind that XBMC simply handles better.

Hi.

Its recorded on a dedicated server, with fast hard disks.

Increasing the file caching solves the problem her too. Thanks.

Do you think its a VLC issue rather that a TVH?

I genuinely don't know - I suspect it's simply the fact that tvheadend is using mkv containers (do you get a different result if you use .ts?) - which can be intensive to demux - and then dumping in a raw stream because of the nature of live TV. In effect, you have a realtime stream with less clever encoding and muxing than you'd get if you could stand back and take your time.

I'm guessing that the tidal wave of information is overwhelming VLC and it needs more breathing space, hence the cache value. So it's not a fault with anything as such, merely a difference in what the programs are expecting to do.

If this creates issues for you, re-wrapping with ffmpeg is really quick (I think that sample took a second or two... much the same as it would take to copy the file) so you could always use a variation of the ffmpeg command line above as a post-processing command, and then you'd almost certainly get something that would play anywhere. If you move the files around, you could re-wrap as you copy - I move my recordings to my NAS after they complete, but prefer to record locally to SSD to make sure there are no bottlenecks, particularly with HD streams, as an example.

Whether there's actually an issue with how tvheadend is creating the file in the first place, though... I'd need Adam or someone more knowledgeable than me to comment there. Certainly my tvheadend files play perfectly on VLC, so there's something about your setup that's different.

Thanks for your reply.

Did some testing with pass-through mode (.ts) mode last night and all the recording are fine, however I need to test it longer to be sure.
Its interesting that no one else has experienced this issue - your right seems to implicate my setup.
My recordings are saved to a dedicated hard disk on the server, Im going to look at the SMART info to see if there a any problems with that hard disk.
Im also using a Hauppauge WinTV Nova-HD-S2 Single Tuner PCI, may I ask what tv adapter you are using?

I've got a Hauppauge (glad you could spell it!) WIN-NOVA-T USB stick for Freeview/DVB-T (identified in tvheadend as a DiBcom 7000PC), and a TBS Q-Box S2 for Freesat/DVB-S and S2 (identified as a Conexant CX24116/CX24118). Both are connected to USB2 ports on a Revo R3600 (Atom N230, I think) with SSD.

I checked back on some of my old recordings - I had a few un-re-encoded ghosts hanging around. Some of them had the odd jitter, but nothing like as bad as that sample you posted, so they basically play fine for me.

My TV tuner uses the Conexant CX24116/CX24118 chipset too but its pci.

If you get a chance please could you just record a bit of BBC news 24 on freesat (its the worst offender) using .mkv and see if it plays on VLC (using the default buffer setting).

Thanks for you help.

Here you go, squire... try this. Should've been from the DVB-S tuner if I got my priorities the right way around, but I'm still working on that :-)

http://www.datafilehost.com/download-92bed865.html

Plays fine on the Atom netbook sitting on my lap, and that's over a 100-ish Mb/s SMB wireless mount as well. There's a slight stutter at about 12 seconds in, but otherwise...

Thanks for that.

Your clip stutters badly on my computer with default install of VLC 2.0.3 Twoflower on linux. Again increasing the caching solved the problem in VLC, however no stutter at 12 seconds?

Right :-

1)When I record news 24 I get stuttering recording on VLC (linux) but increasing the caching solves the problem. XBMC no problems. VLC (windows) stuttering also solved by increasing caching.

2)When you record news 24 (same chipset) VLC (linux) stutters but increasing the caching solves the problem. XBMC no problem VLC (windows) no problem (well slight stutter a 12seconds).

3) .ts recording fine

Im not sure this makes sense!

Thanks for your help.

I wonder if this is related to Bug #1256

Mmm - certainly something about how VLC plays it, I've just tried MPC and it plays flawlessly with the default settings.

I must confess, I've become a little disillusioned with VLC over the last year or so... too resource-intensive, too many crashes. One question for you if I may: if you play your recordings in VLC, what timecode do they start at? I find some of mine start at 00:00 - but most immediately jump to 00:30ish. Not a problem on the whole, but it does confuse when you're trying to edit leading/trailing adverts out. I've never really been able to ascertain whether it's the file or whether it's actually VLC, though.

Anyway, let me know if you want me to test this clip on anything else - I can run it through VLC (and a few other players) on Android, and I can VLC onto a couple of flavours of Linux pretty quickly.

Adam Bark, or anyone else reading this - any way we could nail down if it is something inherent in the mkv muxing or stream versus just a clash with VLC's defaults?

Most of my recordings seem ok on Totem (contrary to what i said in the title). I have a some recordings that even ffmpeg cant fix (from 2.11)

I found one .mkv recording that jumped to 30 at the start with vlc/totem/mplayer

Still no problems with .ts

Im going stick with .ts and use a post processing script to convert to something more widely used.............

Just did a quick test with ffmpeg and .ts recodes to .mkv fine, and plays fine on the default config of VLC (linux). No stuttering.

Mmm, the only issue I have with ts files is that you pretty much have to fix 'em with ProjectX and re-wrap them before you can do anything else bar watch them - at least, that's my experience.

If you want to trim out adverts, for example, ts files don't seem to show timecodes - since they're streams, I guess, so there's no concept of "how long is this programme/clip" - so it's impossible to say "cut the adverts out from xx:xx to yy:yy".

You can re-wrap into mkv as you say, but pop this into mkvmerge and it still won't work - yes, it looks okay, and yes, you can start the cut, but the errors in the ts stream really confuse things as the cut proceeds, to the point at which it just fails. I suspect it's a lack of I-frames or something like that. So I gave up on ts streams and went back to mkv (one of the reasons I settled on tvheadend instead of, say, Argus/4TR) - YMMV, of course, depending on what you want to do.

Have you tried a straight ffmpeg re-wrap of the tvheadend mkv file? Does that help at all (i.e. is it the elemental streams that jitter or is it the container)? It would be just as quick as ts to mkv, and you might have a better-formed file at the end of it. Then again, you might have the same dodgy streams in a shiny new box instead :-)

Prof Yaffle wrote:

If you want to trim out adverts, for example, ts files don't seem to show timecodes - since they're streams, I guess, so there's no concept of "how long is this programme/clip" - so it's impossible to say "cut the adverts out from xx:xx to yy:yy".

That's not true. You just have to split the file before and after the advert using ffmpeg or whatever other software able to understand TS and then do a simple cat. As anyway you have to poke the file to see where the adverts are...

You can re-wrap into mkv as you say, but pop this into mkvmerge and it still won't work - yes, it looks okay, and yes, you can start the cut, but the errors in the ts stream really confuse things as the cut proceeds, to the point at which it just fails. I suspect it's a lack of I-frames or something like that. So I gave up on ts streams and went back to mkv (one of the reasons I settled on tvheadend instead of, say, Argus/4TR) - YMMV, of course, depending on what you want to do.

Recent version of mkvmerge are able to directly convert TS to mkv...

Sorry I re-wrapped to .mkv not recoded

xraynorm - - understand, I was merely wondering if re-wrapping from tvheadend's .mkv to a new .mkv made a blind bit of difference (I ask because of the .ts issues I've had - if you don't have them then clearly it's unnecessary!)

Eric Valette - fair points, maybe I'm behind with some software. I'd need to find a media player that understands the timecodes in a .ts file, then, since VLC doesn't - maybe mplayer or MPC would fare better and allow me to find the adverts in the first place. As I said, I had so many errors in the .ts stream that mkvmerge (while it understood .ts) couldn't parse it properly, so I surrendered - .mkv works for me and I've seen no benefit to changing, unless I change my backend.

And I'm here because I don't want to do that, after all ...!

Just re wrapped my tvhtest.mkv to .mkv with ffmpeg. That fixes it too for vlc.

Thats probably a better way, as its much quicker

Thanks for your help!

Eric Valette - fair points, maybe I'm behind with some software. I'd need to find a media player that understands the timecodes in a .ts file, then, since VLC doesn't - maybe mplayer or MPC would fare better and allow me to find the adverts in the first place.

Vlc on linux understand time code AFAIKT. I personnaly used smplayer (gui for mplayer)

As I said, I had so many errors in the .ts stream that mkvmerge (while it understood .ts) couldn't parse it properly, so I surrendered - .mkv works for me and I've seen no benefit to changing, unless I change my backend.

Recent version (5.8.0) works fine for me although I must say I still use my own version of tvheadend for TS recording... Some bugs related to mkw recoding make me still worry about using the new 3.x code.