Tvheadend

I'd like to see both features. I can play files from XBMC while they are recording, but scanning doesn't seem to work (seek +30s or +10m). For the live buffer, I'd like for it NOT to clear the buffer on change of channels. Channel change often occurs during ad break, and this should not restart the buffer every time. EyeTV stores one buffer across channel changes and it works great.

the reason the seek does not work in a recording has to do with the order of the information inside the mkv. Because tvheadend just stores the mpeg data as received into the mkv it might not always be in the correct order. This is not a problem for normal playback (there is a PTS timestamp on every piece of data, and the player takes care to playback everything in the correct order). But if you want to seek then the player needs to check a lot of data inside the mkv in order to find the new starting point. and some players do not like that and simply refuse to seek.

A possible option is to run the recorded mkv through mkvmerge. There are options to make sure everything is in order, and you can also add additional information to make seeing easier. (but it will increase the size of the recording).

There has been discussions about implementing a live buffer but nothing has been defined or specified.

For me the only problem i have with TVHeadend is the decision to record to only MKV. It means that playing back a recording that is in progress is not really possible. I understand that the MKV format also introduces problems for timeshifting. Some development work was done on a non-MKV format, but this appears to have been rejected, as MKV is the designated future of TVHeadend.

From my perspective, the playback-while-recording and timeshift functions are becoming more requested of a PVR solution. I don't use timeshift, but DO playback during recording.

It seems that the decision to stay with MKV is causing a future feature bottleneck.
I'll double post this into the forums.

Thoughts?

Nathan McAullay wrote:

For me the only problem i have with TVHeadend is the decision to record to only MKV. It means that playing back a recording that is in progress is not really possible. I understand that the MKV format also introduces problems for timeshifting. Some development work was done on a non-MKV format, but this appears to have been rejected, as MKV is the designated future of TVHeadend.

From my perspective, the playback-while-recording and timeshift functions are becoming more requested of a PVR solution. I don't use timeshift, but DO playback during recording.

It seems that the decision to stay with MKV is causing a future feature bottleneck.
I'll double post this into the forums.

Thoughts?

You have TS recording and treaming in my tree: https://github.com/EricV/tvheadend

--eric

Yeh, unfortunately i cant easily test that one as I run tvheadend on a QNAP, and the TVHeadend QPKG is compiled by someone else. I guess I could test build your branch on a different machine (to verify it fixes my issue), then ask the QNAP QPKG maintainer if he can use your branch instead of the one he does use. Does your branch introduce anything else? I would want to ask him to package up a heavily modified TVHeadend, as it might not suit many users. Cheers Nathan

What about recording to the MPEG-4 (container) instead of MKV or TS?

(I'm not sure if the MPEG-4 structure supports live-streaming but I'm pretty sure it does...)

John Klimek wrote:

What about recording to the MPEG-4 (container) instead of MKV or TS?

(I'm not sure if the MPEG-4 structure supports live-streaming but I'm pretty sure it does...)

Probably because its the worst supported solution for off the shelves hardware players (non pc)

Just a short note. I've been using EricV's branch on a QNAP NAS for a month or so, and it is great.
http://forum.qnap.com/viewtopic.php?f=276&t=52511

I have an AC3 aduio issue on one particular channel, but it seems that a rewrite of the VPDAU code in the frodo openelec might be the answer to that.

Also, it seems that there is a whole lot more activity on the tvheadend codebase now, so there is a chance this useful change (or a derivation of it) might make it into mainline.

Thanks Nathan