# What's the longest show you've recorded on your R-15?



## Wolffpack (Jul 29, 2003)

Curious.

With talk that the R-15 filesystem is FAT32 (or based on FAT32) I'm wondering if we'll encounter the 4GB file size limit on shows.

After looking around the drive it appears the files associated with each show are stored in a directory under the root directory. I'm guessing the largest file being the actual video/audio stream.

For SD recordings your recording would have to be somewhere between 4-6 hours depending on the show quality. But on HD shows that's a different story. So I'm wondering what's the longest show anyone has recorded successfully.


----------



## Earl Bonovich (Nov 15, 2005)

I have recorded a couple of the 5hour Olympic Blocks... no problems with them.


----------



## Wolffpack (Jul 29, 2003)

That could be near the 4GB file size. Looks like most SCIFI Friday hour long shows are 700-800MB which would place a 5 hour show about 4GB.

I'm recording HeadLine News from Noon 'till 8:00pm today. See how large that ends up being and if the stream is broken down into multiple files.

Although with HLN over that 8 hour period there's only about 1 hour of programming that's different. Ah well.


----------



## DesignDawg (Jan 8, 2006)

I doubt seriously the shows are individual files. They are probably split up into multiple smaller files like NLEs do with media. There will be reference "master clips" that point to media, and the media files are stored in small blocks. If you think about it, there are many, many benefits to this method, especially in a system where the disk can be always full (buffering).

I'm no R15 engineer, but I am an Avid editor, and I know a thing or two about digital video.

Ricky


----------



## Wolffpack (Jul 29, 2003)

DesignDawg said:


> I doubt seriously the shows are individual files. They are probably split up into multiple smaller files like NLEs do with media. There will be reference "master clips" that point to media, and the media files are stored in small blocks. If you think about it, there are many, many benefits to this method, especially in a system where the disk can be always full (buffering).
> 
> I'm no R15 engineer, but I am an Avid editor, and I know a thing or two about digital video.
> 
> Ricky


I'd agree in theory. In fact the DTivos do exactly that. The audio/video stream is stored in the MFS under multiple file IDs. A one hour show may have anywhere from 4-5 FSIDs. One hour HD programs can have > 20 FSIDs.

But at this time I have 8 shows on my R15. 7 are one hour shows and one is a two hour show. I have 8 directorys under the root directory on the R15 drive and one of them "r31" has a file twice as large as the other 7.

Can't judge on content, just directory and file names/sizes.


```
total 3840
drwxr-xr-x   2 root     root        32768 Feb 18 02:00 11/
drwxr-xr-x   2 root     root        32768 Feb 17 23:00 12/
drwxr-xr-x   2 root     root        32768 Feb 19 05:00 15/
drwxr-xr-x   2 root     root        32768 Feb 18 01:00 17/
drwxr-xr-x   2 root     root        32768 Feb 18 23:00 26/
drwxr-xr-x   2 root     root        32768 Feb 18 03:00 d/
drwxr-xr-x   2 root     root        65536 Feb 17 19:00 e/
-rwxr-xr-x   1 root     root      3130196 Mar 24  2034 jopa*
-rwxr-xr-x   1 root     root         1816 Feb 17 18:47 pcredit.dbf*
-rwxr-xr-x   1 root     root         4976 Mar 24  2034 pman.dbf*
drwxr-xr-x   2 root     root        32768 Feb 18 17:07 r31/
-rwxr-xr-x   1 root     root       239202 Feb 17 16:25 signup.dbf*
-rwxr-xr-x   1 root     root        16104 Mar 24  2034 supp.dbf*
-rwxr-xr-x   1 root     root        52292 Mar 24  2034 xcatgry.dbf*
-rwxr-xr-x   1 root     root         4346 Mar 24  2034 xclient.dbf*
-rwxr-xr-x   1 root     root          532 Feb 18 15:51 xsetup.dbf*

11:
total 790144
-rwxr-xr-x   1 root     root          705 Feb 18 03:00 meta_man.xm*
-rwxr-xr-x   1 root     root       151200 Feb 18 03:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root         8928 Feb 18 03:00 meta_man.xma*
-rwxr-xr-x   1 root     root        11950 Feb 18 03:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 18 03:00 stream.ext*
-rwxr-xr-x   1 root     root     808845312 Feb 18 03:00 stream.str*

12:
total 747776
-rwxr-xr-x   1 root     root         8928 Feb 18 00:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root          705 Feb 18 00:00 meta_man.xmd*
-rwxr-xr-x   1 root     root        20170 Feb 18 00:00 meta_man.xmi*
-rwxr-xr-x   1 root     root        11993 Feb 18 00:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 18 00:00 stream.ext*
-rwxr-xr-x   1 root     root     765591552 Feb 18 00:00 stream.str*

15:
total 849152
-rwxr-xr-x   1 root     root         8928 Feb 19 06:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root        20107 Feb 19 06:00 meta_man.xm\t*
-rwxr-xr-x   1 root     root          654 Feb 19 06:00 meta_man.xmd*
-rwxr-xr-x   1 root     root        12059 Feb 19 06:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 19 06:00 stream.ext*
-rwxr-xr-x   1 root     root     869400576 Feb 19 06:00 stream.str*

17:
total 819584
-rwxr-xr-x   1 root     root         8928 Feb 18 15:53 meta_man.xm\001*
-rwxr-xr-x   1 root     root         8928 Feb 18 15:53 meta_man.xm\001*
-rwxr-xr-x   1 root     root          705 Feb 18 15:51 [email protected]*
-rwxr-xr-x   1 root     root        12088 Feb 18 15:53 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 18 15:53 stream.ext*
-rwxr-xr-x   1 root     root     839122944 Feb 18 15:53 stream.str*

26:
total 891392
-rwxr-xr-x   1 root     root        20107 Feb 19 00:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root          654 Feb 19 00:00 [email protected]*
-rwxr-xr-x   1 root     root         8928 Feb 19 00:00 meta_man.xma*
-rwxr-xr-x   1 root     root        12059 Feb 19 00:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 19 00:00 stream.ext*
-rwxr-xr-x   1 root     root     912654336 Feb 19 00:00 stream.str*

d:
total 849280
-rwxr-xr-x   1 root     root         8856 Feb 18 04:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root       151200 Feb 18 04:00 meta_man.xm\t*
-rwxr-xr-x   1 root     root          705 Feb 18 04:00 meta_man.xmd*
-rwxr-xr-x   1 root     root        11853 Feb 18 04:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 18 04:00 stream.ext*
-rwxr-xr-x   1 root     root     869400576 Feb 18 04:00 stream.str*

e:
total 832256
-rwxr-xr-x   1 root     root         8820 Feb 17 20:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root        20149 Feb 17 20:00 meta_man.xm\t*
-rwxr-xr-x   1 root     root          705 Feb 17 20:00 [email protected]*
-rwxr-xr-x   1 root     root        11996 Feb 17 20:00 meta_man.xmv*
-rwxr-xr-x   1 root     root            0 Feb 17 20:00 stream.ext*
-rwxr-xr-x   1 root     root     852099072 Feb 17 20:00 stream.str*

r31:
total 1609760
-rwxr-xr-x   1 root     root       227669 Feb 18 22:00 aeta_man.xmj*
-rwxr-xr-x   1 root     root        18319 Feb 18 22:00 meta_man.xm\001*
-rwxr-xr-x   1 root     root        13328 Feb 18 22:00 meta_man.xm\002*
-rwxr-xr-x   1 root     root        15956 Feb 18 22:00 meta_man.xma*
-rwxr-xr-x   1 root     root          705 Feb 18 22:00 meta_man.xmd*
-rwxr-xr-x   1 root     root        21584 Feb 18 22:00 meta_man.xmv*
-rwxr-xr-x   1 root     root        18020 Feb 18 22:00 meta_man.xmw*
-rwxr-xr-x   1 root     root            0 Feb 18 22:00 stream.ext*
-rwxr-xr-x   1 root     root     1647968256 Feb 18 22:00 stream.str*
```
Based on this only, I'd guess that "stream.str" contains audio/video data for the shows.


----------



## DesignDawg (Jan 8, 2006)

Wolffpack said:


> Based on this only, I'd guess that "stream.str" contains audio/video data for the shows.


DAG, YO!  I didn't want to even look at that at first, but it drew me in. What you're saying, given that we have no idea what these files are, is a logical interpretation of this stuff. You're really into this, huh? Trying to hack or something, I guess?
Still, even if the R15 stores all that data into one file, it's possible it has a threshold that you haven't reached yet, somewhere under the 4 GB barrier. ??

Maybe one day we'll know.

Ricky


----------



## DesignDawg (Jan 8, 2006)

Nope, nope...

Come to think of it, your 1-hour show is about 1.6 GB, right? 

******EDITED BELOW--I relized I had read you wrong******So, if the 4GB limitation were a limitation to the R15, it would only be able to record up to around 2.5 hours. I recorded a 3-hour movie last night. That'd be almost a 5GB file there, according to our interpretation of this, so, I'm inclined to think the FAT32 issue is not a limitation with this DVR.

Ricky


----------



## DesignDawg (Jan 8, 2006)

OH CRAP!

I just realized you said your shows are 1/2 hour. I thought they were .5/1 hour. OK, so divide my numbers in half. So, yeah, a 5 hour block would be just touching the limit. A 6-hour block should definitely be the test. Easy enough to test, I suppose.

Ricky

P.S.-- In order to record a 6-hour block, you'd no doubt be recording several programs, right? So it would probably split them up that way. Even if not, I will say this: Even if the R15 has a 6-hour recording limit per show...is that really a limitation? I mean, it's so hypothetical. A 6-hour show? Who's watching that?


----------



## ISWIZ (Nov 18, 2005)

I did a 5.5 hr block of the Daytona race yesterday. No problem. It was 4.0 padded 1.5.


----------



## thecougarguy (Feb 7, 2006)

I recorded an 8 hour block of the Barrett-Jackson Classic Car Auction on Speed about a month ago. There were no issues with that recording.

Eric


----------



## Wolffpack (Jul 29, 2003)

An 8 hour show should cover that. I haven't taken a look yet to see what the 8 hours I recorded yesterday look like.

I was curious when I read the file system appeared to be FAT32 just given the nature of that FS. At first I thought that may just be the partition type used in the part table and the format may be nothing like FAT32 but Linux mounted the drive fine as FAT32.

Creating directories for each show in the root directory somewhat suprised me. Generally speaking the root directory for pretty much any filesystem has imposed limitations to the number of file/directory slots that other directories within the filesystem do not have.


----------



## cabanaboy1977 (Nov 16, 2005)

Wolffpack said:


> Creating directories for each show in the root directory somewhat suprised me. Generally speaking the root directory for pretty much any filesystem has imposed limitations to the number of file/directory slots that other directories within the filesystem do not have.


Could this maybe explain why there is a 50 limit on series links?


----------



## Clint Lamor (Nov 15, 2005)

cabanaboy1977 said:


> Could this maybe explain why there is a 50 limit on series links?


Someone made a poor decision. It's something that I think Earl stated they are going to fix in the future. It was probably just a short cut they took in the design as it's easier to deal with a known set limit of something then it is for that same variable to be dynamic. Just a SWAG though as I have never spoken to anyone on the design team.


----------

