My archos player handles knoppmyth files, but uses a fat32 disk format which can't handle the large HD recordings. Is there a simple way to split files into smaller segments?

well, I'm not sure how simple this technique is, but anyway...

copy the recording to a new name using cp, add it to the system using mythfixdatabase or whatever it is that looks for files not found in the database. Can't remember offhand at the moment.

Then edit each recording. Remove the cutlist points, and set one to cut from the middle through to the end. Do the same for the other recording except cut from the start to the middle.

Run transcode on both. You will also probably want to use lossless transcoding for these.

The result will be two smaller files, each half of the recording.

I think you can use head and tail to split the file.

Suppose you use wc (word count) to find that a file is 100 lines long.
head -50 1016_20070323220000.mpg > 1.mpg
tail -50 1016_20070323220000.mpg > 2.mpg

Of course, they're bigger than 100 lines - much bigger. But that's the general approach that (I THINK) I've used to trim down a sample file.

There's no worries about your split not falling on a keyframe or anything like that? That's certainly a nice quick way to size things down if needed.

_________________
Currently Running:
Too lazy to update this with my current hardware, I'll redo it during my next install =)

Seems to me you could use split -C XXXXX to create XXXXX byte-sized files. man split for more information.

Not sure about the keyframe, but if you can merge multiple mpeg files (http://www.mythtv.org/wiki/index.php/Little_Gems) I would imagine the head/tail and split methods should work. Can't hurt to try, as you're not affecting the original file.

Do head an tail work ok on binary files ? I'd imagined they would only cope with ascii files broken by new line chars.

D

There are enough linebreaks to make it work fine, for these files. I don't know if they're randomly occurring, or planned.
But the split command would definitely work better, I think. If for some reason split gave a corrupt second file due to not starting on a fresh line, you could probably do something to shave off the first line, and then you'd be aligned on a "what would have been a fresh new line" boundary, in case new lines actually mean anything.
I didn't know about the split command, but had a hunch that something like that existed.

I don't know that it would work any better, but it would allow one to more precisely control the size of the output file(s)

I don't know much about the makeup of mpeg files so this is simply a theory, but this is where I'm guessing head/tail may work better, by splitting on line instead of byte boundaries.

The trick is finding a good boundary. How many "lines" are in a file? It's easy to see the size in bytes and divide by 2. But lines require counting. I let "wc" run for a little while before killing it, I don't know how long it would actually take to chew through the file. It would probably be ok, just struck me as terribly inefficient.
However... maybe you can get a "close enough" estimate of an "average number of lines in a 1-hr HD show" and keep using that same value. Yes, that would probably work great.

Yeah, wc would definitely take some time to get through a multi-gigabyte file. Unfortunately I don't know of any utilities that would get the line count any faster

At the very least you would have a base to work from. I just ran wc -l on a ~2 second HDTV file (297416 bytes) and it returned 297 lines. Multiplying by 1800 would give you ~535000 lines. EDIT: Obviously this number is not exact and will be affected by your recording settings /EDIT

The thing about using split is that you can choose the number of bytes you want to appear in each file, but I don't know what that would do to an mpeg file if it happened to split on "the wrong spot" (read: byte). For that reason, I would think estimating the number of lines and using head/tail would maintain the integrity of the video better than split. However, using the above calculations I wonder if head/tail would be able to handle 267500 lines?

Interesting possibilities, I may have to test some of these theories tomorrow since I have the day off with my son. Setup a couple of scripts, let 'em run for the day, and see what comes out.

Well, split choked on the size of the file (5562018916 bytes) so that doesn't seem to be the way to go. Reading through the man pages for head and tail, which I admit I had not done in quite some time, reveals that you can use the -c switch to designate bytes instead of lines. I ran this on the same file mentioned above: and ended up with
This was on my backend, a P4 2.4Ghz with 512Mb RAM. Not too bad as far as time goes, IMO. I have not yet attempted to play the results, but so far head/tail seems to be the way to go...

I'm thinking that it wouldn't be that difficult to build a new program to split a recording into multiple segments based either on size or # of segments, basing the new code on the existing transcode program.

I'm tempted to play with doing that, but I don't really have the need for it personally and I'm too damn lazy, but maybe I'll grab the source and screw around a bit.

Is this something that would be actually useful to people or is this something that's largely pointless?

Not useful to me, I found it an interesting query however. Always liked puzzles

tkoster (the OP) may be interested in the endeavor...

Actually I would. These are exactly the type of commands I was hoping for, rather than going through all the hassles of a video editing program or the time of a transcode. If it can be automated to make all the subfiles with a single command all the better.

Slowtolearn, if you (or anyone else) want to do the work for me, all the better. Otherwise, I'll have to raise my level of linux education and figure it out for myself.

I would try the approach I posted earlier: The 2781009458 comes from dividing the number of bytes of the file 2561_20070316150000.mpg by 2. You can redirect the output (the > portion) to any file name you like, so long as the filesystem has enough free space to write it all out. Note that this does not affect the original file - That remains as-is. If you need some help with a script just holler, but you should try it out manually first to make sure it works for you.