Store the directory a program was created in

[Tony Lill <ajlill@…>]

The current strorage group code searches the directories in a storage group in no particular order. This can cause disks to spin up, NFS directories to automount, and basicly create a noticable delay when accessing a program.

This patch causes myth to store the directory in which a program is recorded and use this "last seen in" directory as a place to start it's search. If it's not there, it goes on to the normal search. So if someone moves a recording and doesn't update the table, it falls back to the old behaviour.

THis patch requires a dirname column to be added to the recorded table, as well as a bump in the protocol version (not included in the patch, since who knows what versions you'll be up to when you apply it).

[Tony Lill <ajlill@…>]

Patch against 0.21 mythtv

[Tony Lill <ajlill@…>]

Patch against 0.21 mythplugins

[anonymous]

Tony, why not just store the storage group 'last seen' id rather than a dirname string. It would use less bandwidth for mythproto, it would enhance security by making sure mythtv will not look for files outside the storage directories, it will make the db tables smaller, and its simpler code...

[Tony Lill <ajlill@…>]

Because it's easier for external move scripts to update, since they don't have to grub around in the storage group stuff. Same goes for mythweb, if it ever wanted to use it.

I don't think it will make the code simpler. At the points where I store and use the dirname, I'd have to add an extra lookup to go from id to path or path to id. In fact, in StartedRecording?, all I did was turn a local variable into a class variable. Unfortunately, the code that figures out where to put a new recording is in an inconvenient place for storing the id. That was the first place I looked to store the dirname.

I was concerned about db size and bandwidth, but I would expect, in general, that the dirnames would be relatively short. For example, mine are less than the size of basename, so the bloat would be fairly small as a percentage. There are much bigger tables around, so the increase in db size should be negligable. As for bandwidth, I haven't noticed any degradation using my xbox frontend, which is usually very sensitive to to that. Not hard data, but if it was going to kill anything...

As to security, If you can get into the database to change the dirname in the recorded table, you could also change the dirname in the storage group. Ditto for a man in the middle attack on the proto. Also, anything you could do with dirname, you could also do by adding ../ to the start of basename. I don't think there's anything in myth that strips that sort of stuff out.

[cpinkham]

I'm taking this ticket so I can look at it, but it may be done as part of the patch to start using recordedfile with the optional/last-found dirname in that table. As I have more shows being recorded in HD, but still have a few non-HD-capable frontends, recordedfile has been moving up on my priority list so that I can keep the HD version of a program as well as a (myth)transcoded SD version around at the same time.

[Rob Smith]

(In [20395]) Fixes #5485, adds in a userjob script to set a bookmark at the start of the program if it was recorded with a pre-roll

[Rob Smith]

Whoops, typoed a ticket number...

[cpinkham]

Changing this ticket milestone to 0.23, but this functionality will probably be accomplished as part of a much larger rework to better integrate MythTV and MythVideo? and allow for more code sharing between the two.

[cpinkham]

Moving some things to 0.24 since we're almost at the 0.23 feature freeze.

[cpinkham]

This feature will be accomplished as part of a larger file and seek table database reorg that is in the works. There is no need to keep this ticket open so I'm closing it to help cleanup Trac. Marking ticket as 'duplicate' even though it's not because it's not really a "won't fix" or any other category.