Hey, Jeff, I have another request. For various reasons, I could make use of a parameter in the metafile of each video that details when vidmgr last pushed the video in question to a TiVo. If you decide to implement it, the feature should probably be optional, since many people may not want vidmgr to monkey with their metafiles, but when enabled, it could simply update the metafield with a timestamp that could later be readily sorted in a virtual share in vidmgr.

Hey, Jeff, I have another request. For various reasons, I could make use of a parameter in the metafile of each video that details when vidmgr last pushed the video in question to a TiVo...

Click to expand...

Let me think about this. Up until this point I never write out any metafiles. I'm away from home right now with no access to a PC. I'm not even sure if the metadata code I "borrowed" from Bill McBrine has logic to write out a file. If it does, it might not be too bad. The thing I need to guard against is that I already add items to the metadata in memory, and I'm not sure I want to write them out to disk. I'd need a method to prevent this. I'll let you know in a few days after I get back.

Leslie - I have it working, but I wanted to confer with you on some of the details.

1) There are multiple possibilities for the location of the meta file, including default.txt, and possibly a .meta subdirectory. Here is what I decided on. I NEVER overwrite a default.txt file. If a file named <path>/.meta/<title>.txt exists then I over-write it otherwise if <path>/<title>.txt exists, then I overwrite THAT. If neither exists, then I create a new file - if the .meta directory exists, I create it there, otherwise I create it in the same directory as the video file itself.

2) The format of the timestamp in the meta file. Initially I just had epochtime, but I decided on using the format that other timestamps are using: 2012-08-23T23:42:00Z. Right now I am using GM time (hence the Z) but I could easily use local time.

There is also a new config option - savepushdate - that defaults to false. It needs to be set to true for this logic to be activated.

Let me know what you think. I can finalize it and get it out in a few days.

1) There are multiple possibilities for the location of the meta file, including default.txt, and possibly a .meta subdirectory. Here is what I decided on. I NEVER overwrite a default.txt file. If a file named <path>/.meta/<title>.txt exists then I over-write it otherwise if <path>/<title>.txt exists, then I overwrite THAT.

Well, that works great for me, but will it create an issue for anyone who has a default.txt file and no specific metafiles? Will you then copy the default.txt file to the new file and add the new field? Thinking about it briefly, it seems that would work. Personally, I'm OK with it no matter what, since all my videos have metafiles, but maybe someone else has objections I don't.

..., but will it create an issue for anyone who has a default.txt file and no specific metafiles? Will you then copy the default.txt file to the new file and add the new field?

Click to expand...

This is exactly what I do - the contents of the default.txt file will be written to the new file along, of course, with the new pushDate tag. The original default.txt file will be unaffected and will remain in force for the other files in that directory.

The problem is that the meta data dictionary that I build is actually a concatenation of default.txt, .meta/default.txt, <title>.txt and .meta/<title>.txt, and I have no representation for which data item came from which file. This creates an issue for this request of yours. With my "solution", the "New" meta file will actually overlay the data that was previously read in from the default file. It produces what you want and I don't think it's much of a compromise

The problem is that the meta data dictionary that I build is actually a concatenation of default.txt, .meta/default.txt, <title>.txt and .meta/<title>.txt, and I have no representation for which data item came from which file. This creates an issue for this request of yours. With my "solution", the "New" meta file will actually overlay the data that was previously read in from the default file. It produces what you want and I don't think it's much of a compromise

Click to expand...

Um, well, hold on. Perhaps I am mis-understanding. Vidmgr does not display the contents of a specific metafile along with the default.txt file when the video is selected, so why would the output be a concatenation? I think I understand what you mean by saying the dictionary does not know the file name whence the data came, but I don't see why the output (or input for that matter) would be a concatenation of default.txt and the other files, if they exist. Creating a new file with whatever text was available from an unspecified source (probably default.txt) is just fine, but outputting the union of default.txt and <video name>.<codec>.txt back to <video name>.<codec>.txt would cause real issues. Surely I misunderstand?

It IS a concatenation of sorts. If two or more files have the same tags, then the tags from the latter files will totally replace the tags from the earlier files. If, however, the first file has a unique tag, then that will survive the merge from the successive files. If I then write out a video specific meta file, then that unique tag will show up in the result because I don't record its ultimate source.

Is there a way for an external process on the server to determine if any HME app is in use at the present time? Over in the Linux thread on the Home Media forum I demonstrated a method to implement logrotate for pyTivo. It is fairly easy to check for an active pyTivo transfer, since such a transfer opens a file for reading or writing. Most of the pyHME apps don't seem to keep any particular file open when active, however, and it doesn't look like HME for Python spawns any easily recognizable threads when one of its apps is active. Of course, one can merely restart HME for python without worrying about whether one of its apps is active or not, but that would rather rudely dump the user out of whatever application he is running without warning.

I have two shares (Tivo Share & Tivo Share2) on two different hard disks. Everthing shows up the way you'd think in pytivo and vidmgr.

I want to create a virtual share that combines the two shares. I've created a virtual share using the parameters:
[All Shows]
values=all
groupby=seriesTitle
display=file
sort=file

It almost does what I want, but not quite. I like to see empty folders displayed, the real shares show the folder and a zero count. I'd like to see the jpeg images for the folders in the list. Lastly, I would like my mpgs with no metadata.txt file to be grouped in the actual folders they reside in.

I get why I get the behavior I do. What I would like to achieve is a virtual share that displays everything the way the real shares do, but with the list of folders combined. Is that possible?

That's a tough one. When I am building the virtual shares, I am working from a list of existing videos. The directory they're in just goes along for the ride - it doesn't drive the process. Even if I organized them by their directory (which I probably could relatively easily) there'd be nothing to point me to empty directories.

I'm not saying no - I just need to think about how it could be done. I'll let you know.

Why do you have shares on two different drives? The answer to that may provide the best means of handling your situation.

In the mean time, there are a number of possibilities, depending to some extent on the OS. For example, one solution might be to create a parent directory, share that directory, and then mount both hard drives in the parent directory.

Hmm, yeah. I don't know anything about RAID under OSX, but I did just a bit of reading, and it sounds like OSX is a rather poor choice for a RAID based server. I did see mention of an OSX version of ZFS, though. That might be a long term solution for you. In the mean time, mounting both drives under a single share, as I mentioned before, might work for you.

Hmm, yeah. I don't know anything about RAID under OSX, but I did just a bit of reading, and it sounds like OSX is a rather poor choice for a RAID based server. I did see mention of an OSX version of ZFS, though. That might be a long term solution for you. In the mean time, mounting both drives under a single share, as I mentioned before, might work for you.

Click to expand...

I'm not sure the single share will work for me. I'll investigate.

I don't need all of the items on my Vidmgr share list (e.g., empty folders showing up). If any were possible, it would be just that much better.