Bugzilla – Bug 11286
Add information about "real" command to TrackInfo originated browsing in MLON
Last modified: 2009-09-08 09:12:05 UTC
Whenever you browse somewhere through TrackInfo details (e.g. other albums by artist), the command structure uses "trackinfo item" based commands to do the actual browsing. This way it's impossible for a renderer to identify the menu that is being displayed, e.g. to do special processing. I would like to get some information about whick menu is being displayed (albums, artists, etc.) or (even better) the "real" commands to be used (that is: transmitted to the client). I assume they should be available in some dispatch table. Rationale: iPeng uses non-MLON based menus for some stuff that are more powerful and I want to be able to use these whereever possible.
Could it be that 7.4 (other than 7.3.2) does already do this?
...Except for Internet Radios and Music Services, where it still doesn't do it...
As it's an XMLBrowser-based menu, I don't see how this is possible. The command must be 'trackinfo' for it to work. What did you have in mind?
I'm not talking about the menu itself. What I'm talking about is the menu that spawn from TrackInfo. For example when I get TrackInfo for a U2-Song I get "Artist: U2". When I select that, I want the menu to be called as ["albums", 0, 100, "menu_all:1", "menu:albums", "tags:ljywags", "artist_id:138", "sort:album",] While sometimes it's being called relative to TrackInfo through ["trackinfo", "items", 0, 100, "menu:trackinfo", "item_id:13", "track_id:3062",] The latter is especially true for things like Last.fm, Rhapsody etc. I haven't found out why I sometimes get the "albums" query for Albums and sometimes I get the "trackinfo item_id" query. For radios and music services I always get the trackinfo queries. I mean, these must be pulled off a lookup table so you could issue the command as it is, couldn't you? Unfortunately I just lost my old logs in my latest OSX crash so I can't give you more details. My motivation is that I want to know what kind of menu I'm in since I'm doing context specific menus (e.g. for XMLBrowser) and I prefer those over the MLON menus since you can't get all information on the latter ones and they don't perform well.
OK all of this is defined in Slim::Menu::TrackInfo. It looks like what you want may already be available and is used by SBC. The 'special' menu items are handled differently for each UI. Look at for example the 'jive' hashes. This is extremely ugly but the best we could do until we rewrite all the library code to use OPML.
umgh. You are right, this is ugly. Besides: I read the words but I don't know what they mean. I've had a look at Slim::Menu::Trackinfo and from what I see, it's a big, hand-coded dispatch table :-) I'm talking about getting something through cometd, not Perl, so I assume you mean that's where I should look the stuff up (in the code), right? Now what I see there is fixed dispatch functions, how do I know what becomes assigned which id? My impression also was, that those are dynamically assigned? I suspect the problem is specifically NOT with the hard-coded handlers, those use "albums" queries or such. My problem seems to be with the XMLBrowser handlers added in the very last line of code: Slim::Control::XMLBrowser::cliQuery( 'trackinfo', $feed, $request ); I suspect this is adding Rhapsody, Last.fm and whichever else handler there are, right? Those generate the kind of menus I mentioned above and unless you've got a way how I can now what "item_id:13" actually means (it's the offset for the feature) I'm a bit lost here.
I think SBC gets the correct command, i.e. 'albums' and is able to render an album-specific menu. Do you not get the same data?
Please read my comment above. For "Albums" I get "albums", which is fine. Check. For "On Last.fm Radio" I get something like "trackinfo items 0 100 menu:trackinfo item_id:13 track_id:3062" Which is not at all helpful, I would need the underlying "lastfm <whatever>" command or at least a hint that I can pass the command I get on to an XMLBrowser menu.
Unfortunately it doesn't work that way. What's wrong with just calling the command given? It goes via TrackInfo to the On Last.fm callback handler.
What's wrong is that I get an MLON menu insteaf of an XMLBrowser one. That said: When I originally filed the bug I _never_ got any "albums" commands but _always_ got "trackinfo whatever" commands which led to iPeng opening up MLON menus for these queries. I don't know why that was, the "Version" in the bug says 7.3.1 so it was maybe before I upgraded to 7.3.2, can't reproduce it now. That was what really troubled me. As long as I can be sure that the current behavior WRT library queries doesn't change, I think I can live with it, capabilities of my MLON renderer and my XMLBrowser renderer are quite similar, the XMLBrowser one just performs better and has a little more obvious UI.
OK, well 'trackinfo items' is an XMLBrowser menu.
You mean I can just strip the "menu:whatever" parameter and dump the output on my XMLBrowser browser? That does indeed solve it completely.
Should be able to, the "menu:foo" tag just enables the extra MLON data.
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
For some reason Bugzilla did not change the target when I did this yesterday. Or maybe it was me. In either case, I'm trying it again.
Moving 7.4 bugs to 8.0.