[mythtv-users] Virtual file from multiple files

[Gert]

Marc Randolph schreef:
> On Thu, Jun 19, 2008 at 4:07 PM, Gert <gertk at xs4all.nl> wrote:
>   
>> Hi,
>>
>> 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
>> tuner.
>>     
>
> 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:

0002E3620BF1_121251780010001.crid

(the last 4 digits are the channel number, the 1 prepending it seems to 
be fixed)

With some scripting I managed to extract the programname, timestamp and 
recording directory from this:

recording directory in this .crid file points to: 
0002E3620BF1_1212517531.fmpg

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

.rec/0002E3620BF1_1212517531.fmpg

there are these files:

0002E3620BF1_1212517531.fmpg
0002E3620BF1_1212517531.fmpg.000.mpg
0002E3620BF1_1212517531.fmpg.000.mpg.idx
0002E3620BF1_1212517531.fmpg.000.mpg.midx
0002E3620BF1_1212517531.fmpg.001.mpg
0002E3620BF1_1212517531.fmpg.001.mpg.idx
0002E3620BF1_1212517531.fmpg.001.mpg.midx
0002E3620BF1_1212517531.fmpg.002.mpg
0002E3620BF1_1212517531.fmpg.002.mpg.idx
0002E3620BF1_1212517531.fmpg.002.mpg.midx
0002E3620BF1_1212517531.fmpg.003.mpg
0002E3620BF1_1212517531.fmpg.003.mpg.idx
0002E3620BF1_1212517531.fmpg.003.mpg.midx

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

Gert