PyTivo Video Manager HME App for pyhme

Shortcuts are not the same as symlinks, but that's a different discussion for another thread.

Click to expand...

Well, OK, that's true. Windows Vista introduced an attempt at an analog to a *nix symlink, but I'm not sure whether in this context the distinction matters, or not. Whether it is a true symlink or a "shortcut", I suspect the system has to go through the same or similar gyrations in order to determine whether the link is unique, or not. I could be mistaken, of course. Perhaps jbernardis will chime in.

It seems like the default path is the uncommon configuration case on Windows. In my opinion, most Windows users have no idea how to create a symlink. Perhaps a config option whether your windows systems contains symlinks or not would increase usability.

Click to expand...

Let me look at the code to see what I can do here. If it's simple to simply turn off the logic if you do not have any links, then I will ad an option for doing so.

Also, first timers would benefit by either having the distribution config file have the default values prepopulated or having better error recovery in the program.

Click to expand...

My intent with the distribution file was to show you where you need to enter values, not to provide a syntax that results in the default values. I sorry that mislead everyone. You do NOT have to enter the default values - simply remove or comment out the line in the file and the default value will be used. Next distribution will have these lines commented out.

OK - version 2.0d is up on git. I'm kind of eager for someone to let me know if there is an improvement under windows. Basically I added a new vidmgr.ini option - usefileid - the default value is true.

If you set it to false, it bypasses the logic used to determine the file's unique ID. This means that if you DO have links (hard or soft) vidmgr will treat them as two different files and they will show up twice (or more times) in the virtual shares.

If you set it to true, the logic of today is used, and the unique ID for each file is determined so that the duplication does not happen.

BTW the simplest way to do this was to leave the existing routines in place and instead of returning the actual file ID, I return a sequential number - that way, each file is given a unique number and there will never be a match.

I also editted the two dist files to comment out the lines that everyone thought was bringing in the default values.

Is there a way to build the Thumbnail cache without having to click on each individual movie? My thumbnails are created with Thumbgen and are about 1MB a piece so it takes a long time to load each one nd I have over 1,500 movies with thumbnails.

Click to expand...

The thumbnail cache is built automatically, but it is statically sized at 100 entries. You CAN increase this by playing with the value of thumbcachesize in Config.py, but I would tend to agree with lrhorer. 1MB is a VERY large thumbnail. I have about 600 videos, and for the most part my thumbnails are images of the DVD case. They range in size from 30K to 70K and they look fine. They also load very fast even if they are not in the cache.

OK - version 2.0d is up on git. I'm kind of eager for someone to let me know if there is an improvement under windows. Basically I added a new vidmgr.ini option - usefileid - the default value is true.

If you set it to false, it bypasses the logic used to determine the file's unique ID. This means that if you DO have links (hard or soft) vidmgr will treat them as two different files and they will show up twice (or more times) in the virtual shares.

If you set it to true, the logic of today is used, and the unique ID for each file is determined so that the duplication does not happen.

BTW the simplest way to do this was to leave the existing routines in place and instead of returning the actual file ID, I return a sequential number - that way, each file is given a unique number and there will never be a match.

I also editted the two dist files to comment out the lines that everyone thought was bringing in the default values.

Click to expand...

It took about 2 minutes to load with dynamic cache the first time on my system with about 10,000 media files. Subsequent loads took about 45 seconds. That's better than before where it would drop back to live video before completing but it is still slow for regular usage.

With a static cache, vidmgr loads in 5 seconds on my system.

One potential problem that could happen by setting usefileid=false would be if someone had nested shares. Not quite the same as symlinks, but could cause multiple entries per file in virtual shares.

Thanks for putting this in so quickly, however I think I'm going to revert back to static cache with a daily run of buildcache.py.

Is there a way to build the Thumbnail cache without having to click on each individual movie? My thumbnails are created with Thumbgen and are about 1MB a piece so it takes a long time to load each one nd I have over 1,500 movies with thumbnails.

I have tried the "BuildCache.py" but that doesn't seem to build the thumbnails, just the shares I have in my pyTivo.conf. I also tried "ThumbCache.py" but that didn't seem to do anything. any help would be greatly appreciated.

Click to expand...

Well, I was so frustrated (with TiVo, not Video Manager) that I went through and opend up EVERY port that TiVo had on their website. I have 2 routers (Netgear WNDR3700 for N capabilities connected to my Verizion FIOS MI424WR) and opened up all the ports on BOTH routers, including the pyTiVo and Video Manager ports and did the same on my Windows firewall. After about an hour of entering ports EVERYTHING is BLAZING fast, even with my 1MB thumbnails! I can't believe it but there is ZERO lag when I start Video Manager and when i go from one video to another the thumbnail pops up instantaneously.

Even though my TiVo always said that the port configuration passed I always had issues with the HD menus, the top banner going blank in TiVo Central and when i would run pyTiVo, Stream Baby or Video Manager, the whole TiVo tended to freeze up and get the green circle of death. I have no idea which port on which router or windows firewall did the trick but something fixed it. I guess time will tell if it fixed my actual TiVo HD issues that everyone has been havning but at least I can now browse my WONDERFUL and GORGEOUS Video Manager Thumbnails with ease.

One thing I've learned in 30+ years of software development - software is never finished.

With that in mind, I have just posted version 2.0e on GIT. There was a nasty bug when parsing virtual share options - once it found one option, it stopped looking for any others. So if you tried to alter more than one option, only one of them would have been used. I'm actually surprised nobody reported this before.

I couldn't be satisfied with just a bug fix. There are two new features as well:

I added the shares= option to the vidmgi.ini to limit virtual shares to a list of pytivo shares, and

I added a new virtual share type - alpha=tagname - that produces a folder for every letter (or digit) that the named metadata item begins with

SO for example, the following lines in the ini file:

Code:

[alphabetical movies]
alpha=title
shares=My Movies

will produce a virtual share of movies (from the "My Movies" share) that are arranged into seperate folders based on the starting letter of the title. So there will be an "A" folder, a "B" folder, etc. Digits are also used, and then a catchall <other> folder. If there are no titles for a given letter, that folder does not appear.

Apparently this win32file thing has been an issue for some. I didn't anticipate this since I didn't explicitly install this module on my PC - it came with python 2.7.

It's available as a separate download - just google it. The question I have is whether it is compatible with 64 bit python - I am using 32 bit. If someone could chime is as to whether this module works in this environment, I'd appreciate it.

Apparently this win32file thing has been an issue for some. I didn't anticipate this since I didn't explicitly install this module on my PC - it came with python 2.7.

It's available as a separate download - just google it. The question I have is whether it is compatible with 64 bit python - I am using 32 bit. If someone could chime is as to whether this module works in this environment, I'd appreciate it.

I'm not sure where it is because like I said it came with my 2.7 install (I have activestate python), but others in this thread have mentioned downloading it. Perhaps if they see this, they can post a download link.

I'm not sure where it is because like I said it came with my 2.7 install (I have activestate python, but others in this thread have mentioned downloading it. Perhaps if they see this, they can post a download link.

Active State is a company that packages python and other languages for business use. They charge for their normal products, but also provide free versions for personal use. I originally started using their products when I was more into perl, and have been happy with them.

I'm not sure where it is because like I said it came with my 2.7 install (I have activestate python), but others in this thread have mentioned downloading it. Perhaps if they see this, they can post a download link.

Click to expand...

Found the Win32 extensions and have it working with all 32 bit software. Since I have Win7-64 bit I'm going to try duplicating my success with all 64 bit versions of Python 2.6.5, PIL 1.1.7 and pywin32 build 216. Thanks for the quick responses

Found the Win32 extensions and have it working with all 32 bit software. Since I have Win7-64 bit I'm going to try duplicating my success with all 64 bit versions of Python 2.6.5, PIL 1.1.7 and pywin32 build 216. Thanks for the quick responses

How can I get the filename to display in the info screen (when I press the remote info button). It appears I have recordings of shows where the metadata says they're an episode Title that they aren't and I need a way to identify what files they are. Would be nice to get filename.ext displayed. I tried editing the vidmgr.ini to include the following, but it didn't display the filename

What significant advantage do you see (or expect) from running 64 bit vs. 32 bit ?

Click to expand...

None. Other than it's easier to remember always run 64 bit unless it's not available or causes incompatability issues. I already had 64 bit Python 2.6.5 and had been using it with pyTivo. In order to run vidmgr I had to get PIL and the win32 extensions. They all have to be matched (all 32 bit or all 64 bit). I decided since I have a 64 bit processor and a 64 bit OS, I'd stick with 64 bit Python and extensions since they're available.

None. Other than it's easier to remember always run 64 bit unless it's not available or causes incompatability issues. I already had 64 bit Python 2.6.5 and had been using it with pyTivo. In order to run vidmgr I had to get PIL and the win32 extensions. They all have to be matched (all 32 bit or all 64 bit). I decided since I have a 64 bit processor and a 64 bit OS, I'd stick with 64 bit Python and extensions since they're available.

Click to expand...

That's reasonable. I follow the opposite policy (always install 32-bit versions). It's simpler and I've yet to see an application that had significant performance advantages using an (available) 64-bit version. Transcoding seems like it would benefit since it is compute-intensive, but I don't think the 64-bit versions of the transcoding software I use are available in general.

That's reasonable. I follow the opposite policy (always install 32-bit versions). It's simpler and I've yet to see an application that had significant performance advantages using an (available) 64-bit version. Transcoding seems like it would benefit since it is compute-intensive, but I don't think the 64-bit versions of the transcoding software I use are available in general.

Click to expand...

You can get 64-bit versions of x264.exe and ffmpeg.exe. Not sure what you use to transcode (besides VRD, if anything). I have done very little straight transcoding (always process with avisynth), but with 64-bit avisynth and 64-bit x264, I could see ~10% higher conversion speeds. 64-bit avisynth wasn't particularly stable though, so I reverted back to 32-bit.