Separate names with a comma.
Discussion in 'Developers Corner' started by jbernardis, Apr 20, 2011.
Here i am to cause you a headache tonight it seems.
Current config file
If i take the # off of the apps line to make it load only the vidmgr i get the following
Which at first appears good but if i try to access it from the Tivo the screen pops ip black and says please wait and nothing more and nothing more is shown in the command window i have given it 15 mins should it take longer then that?
Got it working, it finally complained about a bad folder on my G drive so i commented out the reference to it in pytivo config file and i got my other two drives to work.
I will have to look into that further.
The purple and blue background works fine.
I am running python 2.6 as that is what was recommended when I installed pytivo many moons ago. Never saw any reason or recomendation to change it. If 2.7 is required, is it compatible with pytivo including the photo module?
Ok, installed pywin32 for python 2.6, finished working through the ini file and again attempted to start vidmgr2...
Now gives the following error on launch of pythonHME
Skipping: vidmgr2 - No application class
Returning to running vidmgr version 1 runs fine.
Seems odd but reading through this thread, it appears no one else is trying to get Ver2 going or has tested under windows?
Are you still running this on your Syno? I got a similar error when I tried to upgrade from vidmgr v1 to vidmgr v2. Initially, I downloaded v2 into a folder called vidmgr2. HMEforpython didn't like two folder with nearly the same name it seems. I had to move the v1 folder outside of hmeforpython and only run 1 folder for vidmgr. That fixed the error message for me.
The issue is with python's naming rules. The class name in the __init__.py module has to be the same name as the directory but capitalized. I'm not sure if the capitalization is necessary, but python seems to allow it. If you put your files into a directory named vidmgr2, you need to open up the __init__.py file and change the name of the class to be Vidmgr2. you also need to change your entry in config.ini to be vidmgr2.
I assume the nonUniquename was coming because you had multiple services with the same name. That message actually comes from pyhme code. If you do not have an apps= line in your config.ini file, pyhme tries to start up EVERY subdirectory as an app. Apparently two of them have the same name or somehow conflict with one another. Isolating it to vidmgr eliminated the conflict.
Thanks guys. Will give this a try when I get home tonight. I placed the new version in vidmgr2 so I could keep the functional version 1 online while I worked out the bugs.
I am not running it on the Synology diskstation, I went back to the windows server for pytivo, pythonHME, Harmonium and a few other full time tasks.
OK, making progress. I got vidmgr2 running and have 2 virtual shares. Movies by Genre and Movies by Actor. Now I need to find a way to filter and combine the results into fewer folders. For example there are 11 different folders shown for dramas, romantic drama, crime drama etc. Similar for action and others. vidmgr came up with 62 genres from my approx 300 films. Its also including tv shows but I suppose I will need to define multiple shares in pytivo to break those out.
Some suggestions on how best to use this?
There's nothing you can do that's intrinsic to the software as it is - except manually change the genre in your metadata files.
Maybe I could come up with some grouping method, where within the virtual share, you could create virtual values that map to a set of real values. If the metadata is within the set of real values, then use the virtual value. Let me experiment a bit. No promises.
Is there something I am supposed to be doing to have vidmgr2 save the cache? When it lauches from the tivo menu, it takes 4 to 5 minutes to start. No problem the first time but comming back some time later and reentering video manager, it takes a long time again to 'Processing video share Video on Meda Server'
The share has 6580 videos according to vidmgr.
As this is, taking so long to start, its is not useful to other members of the family.
There are two strategies to dealing with the cache. All of this is explained in the readme file.
1) You can build the cache ahead of time by just changing to the vidmgr directory and entering "python BuildCache.py". If you do this, it will speed up startup time, but you will be responsible for updating the cache if adding/deleting files, etc. You can rebuild the cache using the above method (I do mine as a cron job) or you can rebuild the cache through the tivo interface by pressing thumbs-down three times in succession. Also, if you prebuild the cache, and then delete a video through the tivo interface or rebuild the cache via the remote control, it will save the cache on exit.
2) You can build the cache dynamically. If vidmgr doe NOT find the cache on startup, this is the method it assumes. In this case, the cache is NEVER saved by the application as it knows it will just rebuild it on the next entry.
It sounds like you want option 1. I'm not sure how to set up the equivalent of a cron job on windows, but you can always force a rebuild with the remote control.
BTW - the current GIT has a bug. If you try to rebuild the cache through the remote control twice, it will fail the second time unless you exit the app first, and then re-enter. I have a fix and will be uploading shortly. I have something else I'm trying to work out first.
Thanks, I did not get the part where if it built the cache on startup it would not save it. Manually building cache from a command line now.
Do I need to stop vidmgr2 when building the cache each time or will it use the new cache next time it is accessed without a restart?
Building manually from a command line is fine, I can create a shortcut.
Thanks for the help. Looks like I am close to leaving V1 behind and being current revision.
Thinking a bit more about the virtual shares, what I think is needed is some sort of metadata cleanup utility or an extention of MetaGenerator to help. The data is the problem, not vidmgr.
If you double-click on the Genre list in MG3 you can edit it, including deleting items. This won't be useful if you're auto-processing all TV shows in a folder of course. Let's discuss your ideas for the desired "extension" either here or in the MG3 thread (link in signature).
vidmgr is not a process it is a thread that is only active from the time that you choose it on the tivo menu until you exit either back to live TV or back to the tivo menu. The process that controls vidmgr is pyhme.
When you rebuild the cache, you do NOT need to restart pyhme. You DO, however, need to restart the vidmgr thread by exiting the app and re-entering.
I'm glad to hear this. I had an idea in mind and actually started implementing but it quickly became more than I wanted to do. Not the actual algorithm - that was pretty straight-forward - but the amount of parsing I'd have to do to protect myself from the arbitrary text that could be used in the metadata values.
I quickly backed the changes out.
I attemted to stir up a conversation over at your MG3 thread for this. Lets see where it leads with your help. Thanks for taking an intrest in this.
Thanks to dlfl, I now have a very consice list of 14 genres and they present perfectly in vidmgr as virtual shares. Also created virtual share for movies by actor, by year, by mpaa rating and by star rating.
I also set up a few net shares in pytivo to mesh well with the virtual shares.
And all the funny business with symlinks is gone. YES!
Now we come to a request for jbernardis,
When vidmgr presents the list of pytivo shares and virtual shares, the pytivo shares are listed first, in the order listed in the pytivo.conf file and then the virtual share in the order they are listed in the vidmgr.ini file.
Can you add an option to show this list of share sorted alphabetically so that all my movie shares and television share are displayed together?
Thanks for the great work everyone. This great tivo add on has just become far more useful. Just amazing.
Shouldn't be too tough - let me have a look at the code. I owe everyone an update anyway for the fix I mentioned before - I'll try to get this in there too.
The version out on GIT has been updated: version 2.0c. there is a new option: sortroot - set to either true or false, false is the default.
If set to true, then the root directory is sorted with virtual shares AND physical shares together.
If set to false, the physical shares appear first - sorted - followed by the virtual shares - which will also be sorted.
ALso at this time, I fixed the bug where you couldn't build the cache a second time with the remote control.