Bug 17732 - Third party title formats no longer supported in browse menus
: Third party title formats no longer supported in browse menus
Status: RESOLVED INVALID
Product: Logitech Media Server
Classification: Unclassified
Component: Player UI
: 7.7.0
: PC Other
: -- normal with 12 votes (vote)
: ---
Assigned To: Unassigned bug - please assign me!
: onebrowser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-06 01:04 UTC by Erland Isaksson
Modified: 2014-03-13 06:37 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erland Isaksson 2011-11-06 01:04:32 UTC
It looks like support for third party title formats no longer works after onebrowser was introduced in 7.6. Any title format added by a third party plugin is never shown in the browse menus.

It works in current playlist but not in browse menus.

The consequence is that any data provided by third party plugins can't be displayed in browse menus, this includes but is not limited to:
- Ratings from TrackStat plugin
- Custom tags scanned by Custom Scan plugin
- Libraries defined by Multi Library plugin

The issue exists both in 7.7 and 7.6, in both player and web interfaces.

If my investigation is correctly the following is the problem:
- The call to Slim::Music::TitleFormatter::infoFormat from browse menus always pass a "meta" structure
- The call is made from Slim::Control::XMLBrowser::_cliQuery_done which gets the data for the "meta" structure from the underlying CLI query.
- I think the underlying query is handled in Slim::Control::Queries::titlesQuery where it's not possible to hook in any third party data.

I haven't analyzed in detail how to solve this but I guess having some logic in Slim::Music::TitleFormatter to handle format items which is not part of the "meta" structure would be the easiest.
Comment 1 Michael Herger 2013-09-12 08:18:36 UTC
Assuming you've registered a format handler for your custom format, isn't it called with the meta hash? This includes the track's ID which would allow you to get the data you need, doesn't it? A bit expensive, probably, but possible.
Comment 2 Erland Isaksson 2014-03-13 06:37:24 UTC
As Michael suggested, this was caused by a changed API behavior.
The problem TrackStat plugin had with this have now been corrected in the just released 3.1.3906 version of TrackStat.

The title format callbacks in 7.6.0 and later returns a hash instead of a Slim::Schema::Track object, the content of the hash looks for example like this.

          'id' => '4202',
          'title' => 'Captain Nemo',
          'duration' => '4:02',
          'tracknum' => '12',
          'url' => 'file:///mnt/flacmusic/Ace%20Of%20Base%20-%20Flowers/12%20Captain%20Nemo.flac',
          'remote' => 0,
          'genre' => 'Dance',
          'artist' => 'Ace of Base',
          'albumartist' => 'Ace of Base',
          'trackartist' => 'Ace of Base',
          'album' => 'Flowers',
          'year' => '1998',
          'type' => 'audio',
          'bitrate' => '918kbps VBR',
          'filesize' => '27885044',
          'ct' => 'flc',
          'secs' => '242.733',
          'fs' => '27885044',
          'hasMetadata' => 'track',
          'name' => 'Captain Nemo',
          'playall' => 1,
          'play_index' => 11,
          'index' => '2.0.11',
          'hasmetadata' => 'track'