Opened 11 years ago

Closed 9 years ago

#5485 closed enhancement (duplicate)

Store the directory a program was created in

Reported by: Tony Lill <ajlill@…> Owned by: cpinkham
Priority: minor Milestone: unknown
Component: MythTV - General Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments (2)

dirname (9.0 KB) - added by Tony Lill <ajlill@…> 11 years ago.
Patch against 0.21 mythtv
dirname.mythweb (1.1 KB) - added by Tony Lill <ajlill@…> 11 years ago.
Patch against 0.21 mythplugins

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by Tony Lill <ajlill@…>

Attachment: dirname added

Patch against 0.21 mythtv

Changed 11 years ago by Tony Lill <ajlill@…>

Attachment: dirname.mythweb added

Patch against 0.21 mythplugins

comment:1 Changed 11 years ago by 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...

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham
Status: newassigned

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.

comment:4 Changed 11 years ago by Rob Smith

Resolution: fixed
Status: assignedclosed

(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

comment:5 Changed 11 years ago by Rob Smith

Resolution: fixed
Status: closednew

Whoops, typoed a ticket number...

comment:6 Changed 10 years ago by cpinkham

Milestone: unknown0.23

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.

comment:7 Changed 10 years ago by stuartm

Component: mythtvMythTV - General

comment:8 Changed 10 years ago by cpinkham

Status: newassigned

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

comment:9 Changed 10 years ago by cpinkham

Milestone: 0.230.24

comment:10 Changed 9 years ago by cpinkham

Milestone: 0.24unknown
Resolution: duplicate
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.