Hi James, > James Trietsch wrote: > Unfortunately, the RM plugin seems to make its own rules when creating the > lists of TV programs. It creates them as RecordedProgramItem which is derived from VideoItem.
>They weren't even classified as type 'video'. They are! What revision are you using? Since Revision 9842 RecordedProgramItem inherits from VideoItem and thus have type='video'. I just testet it, at the end of __init__ of RecordProgramItem it has self.type == 'video', as expected. It also ought to have all ItemPlugins for video automatically, e.g. I see the "Delete"-Actions from file_ops.py... > So I made them type 'video'... and opened up a whole new can of worms when > the bookmarker noticed the shiny new 'video' items. > Long story short, I've looked over the properties that get added to a video > item in video_item.py, and I've added 'variants' and 'subitems' properties > both empty) to keep the bookmarker happy, so at least the menu will display > without throwing an error popup. Strange! Both subitems and variants should always be there (both empty), as each RecordedProgramItem calles the init function of VideoItem in its own init function. Do you know of the python building dir(), which shows you all attributes of an object? Try it in a print statement at the end of __init__ of RecordedProgramItem (print(self)), you will see, that both list are there. I just tested and found, that the bookmarker is not working correctly for RecordedProgramItems in the current svn. But this can neither be a problem of the missing type, as it *is* correctly set to 'video' nor of the missing lists, as they also *are* there. But there is definitely something not right here. The question is, what else did you change? What I found on my very quick test is: 1) When I start to play and then stop it again, I will not see the resume option in the submenu 2) When I reopen the RM after exiting it completly, the resume options are there ----> These two points might be due to not updating the submenu correctly 3) When all recorded programs have the same name and differ only in the recording date, then it seems to happen, that no matter what program I choose to resume, it always resumes the same one ----> Problem of Bookmarker, how does it find the spot to resume from? >> Now the problem is (and actually always has been while using the RM plugin) >> when you go to set a bookmark while watching a TV program, it wrecks. Like >> so: >> >> 2007-12-18 20:07:42,730 CRITICAL main.py (484): Crash! >> Traceback (most recent call last): >> File "/usr/lib/python2.4/site-packages/freevo/main.py", line 472, in ? >> MainTread().run() >> File "/usr/lib/python2.4/site-packages/freevo/main.py", line 325, in run >> self.eventhandler(rc.get_event(True)) >> File "/usr/lib/python2.4/site-packages/freevo/main.py", line 275, in >> eventhandler >> if not rc.app()(event): >> File "/usr/lib/python2.4/site-packages/freevo/video/plugins/mplayer.py", >> line 426, in eventhandler >> return self.item.eventhandler(event) >> File "/usr/lib/python2.4/site-packages/freevo/video/videoitem.py", line >> 652, in eventhandler >> if self.plugin_eventhandler(event, menuw): >> File "/usr/lib/python2.4/site-packages/freevo/item.py", line 438, in >> plugin_eventhandler >> if e(self, event, menuw): >> File >> "/usr/lib/python2.4/site-packages/freevo/video/plugins/bookmarker.py", line >> 171, in eventhandler >> videoplayer = self.item.player.name >> AttributeError: 'NoneType' object has no attribute 'name' I could not reproduce that. For me it is not crashing! But see above, I do have other problems, maybe they are obsuring you problem. Unfortunately I do not have other programs to test on at the moment. > I know what the problem is: my TV items don't have a player.name property. > And I know what bookmarker is using it for (Xine needs a playlist file while > mplayer can just take command-line arguments) > And I can even see in video_item.py where it selects the best player from a > list and assigns it to item.player. > But I cannot find where item.player.name is set! I've searched the whole > /site-packages/freevo structure for 'player.name' > and only get hits in bookmarker.py obviously) and dvdimage.py. OK you have already found out a lot, but step by step: 1) RecordedProgramItem is created on the base of VideoItem, thus it calles the __init__ function of VideoItem 2) In the __init__ function of VideoItem the function set_url() is called. This function is quite important as it sets the player for each VideoItem. The prefered player for each VideoItem is dependent on the url, thus it is important to call set_url() if you want to change the url and not do it directly 3) If you look at the player rating and sorting part in set_url(), you see that it starts with plugin.getbyname(plugin.VIDEO_PLAYER, True) This gives a list of all registered VIDEO_PLAYERS, which are normally mplayer.py and xine.py, but can also be vlc.py. As you can see already in the set_url() function, those players all have a name attribute (see in video/plugins/mplayer.py, /video/plugins/xine.py and /video/plugins/vlc.py). > I'm happy to add the proper code to recordings_manager myself (I'm actually > really enjoying picking Freevo apart > and tinkering and I hope my contributions will be useful) Any help is always welcome! > For what it's worth, RMs play function turns right around and calls the > video_item.play function, then does some housekeeping afterward. Right, it overwrites the play function in VideoItem, because the housekeeping has to be done here, and it can not go directly to VideoItem because it is RM specific. >> I wanted to make the TV items type 'video' so they would get the 'Transcode >> Video' menu item from the encoding_client. I am still no seeing, why this is not working out of the box. Is there maybe some other conditions in 'Transcode Video', that were not fulfilled by RecordedProgramItems? > I'd like to crush programs that I planned on keeping, to save space. This did > work, by the way: Once the items became type video, > they got the additional video menu items too. But maybe there's an easier way > to do it? Call something in video_items.py instead of reinventing the wheel? > I'll look into that too. Here some more investigations are needed! As everything should be already in VideoItem and therefore should be automatically available for the derived class RecordedProgramItems. I hope this helps you a little and shows you in what direction you should investigate further. Anyway, keep up your fun in poking around in freevo, as there is a lot which is not solved optimal, the code is not always very pretty and there are always hidden bugs. So help is always more than welcome! Tanja ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
