[mythtv-users] Virtual file from multiple files
gertk at xs4all.nl
Sun Jun 22 11:59:21 UTC 2008
Marc Randolph schreef:
> On Thu, Jun 19, 2008 at 4:07 PM, Gert <gertk at xs4all.nl> wrote:
>> Currently I am experimenting with a Siemens cable tuner (DVB-C with
>> smartcard) which is capable of recording to a network share (Samba).
>> However, it records in an odd way (probably to makes things difficult)
>> it produces small blocks of mpeg TS files ( 2 minutes each) which when
>> combined (by simpy cat-ting together for example) form a complete
>> recording in TS format.
>> My question is:
>> Is there a way to 'link' these blocks together into one new virtual file
>> and add this virtual file to the backend recording database ?
>> My goal is to control the Siemens from the backend by sending IR
>> commands (the only way to control it...) and use it as an external DVB-C
> Very interesting. Do all the TS files in a single directory apply to
> that one stream? If there were multiple devices creating multiple
> streams, could a program tell the difference, or else could the
> different streams appear in different directories?
The Siemens creates in the top recording directory a .crid file in which
the name of the program, timestamp(s) and recording directory name (and
lots of other binary stuff) is written.
The crid file itself is named 'macaddress_timestamp1channel.crid' like:
(the last 4 digits are the channel number, the 1 prepending it seems to
With some scripting I managed to extract the programname, timestamp and
recording directory from this:
recording directory in this .crid file points to:
In a hidden directory named '.rec' these directories are created by the
Siemens and named 'macaddress_timestamp.fmpg' in which the segmented
stream and index (?) files are written:
So in this directory (from the top recording directory):
there are these files:
(mac address in this list is altered by me)
> How are the files named - or said differently, how would a program (or
> slim driver) know which filename to start with, and which file to move
> on to next? Presumably naming wraps around at some point - when?
> I guess your controlling program could delete a TS file at some point
> after it had moved to the next one.
> Assuming sane answer to the above, this doesn't seem overly
> complicated, but it does double your disk activity:
> * Siemens is writing small TS files
> * stub is reading small TS files and passing them to mythbackend(?)
> * backend writes them back out as one big seekable file
> * frontend reads it back
> A better method would be to have the Siemens writing the TS files to a
> tiny ram-disk like filesystem, and keep the number of TS files small
> by deleting them quickly.
I will try and fiddle a bit more with this.. The picture quality is so
much better than with the analog recordings from the PVR500 especially
since most channels on the cable here are broadcasting in letterbox
format and much detail is lost.. On the digital channels programs are
being broadcast in full resolution 720x576 when 16:9.
More information about the mythtv-users