Hi,

is there an easy way to retrieve the playlist number and index for a metadb_handle inside a metadb_display_hook?

Or maybe there is a better solution to what I want. I have a playlist_callback_static-derived service that calculates and stores some things for each song in each playlist and stores it by playlist number and playlist index. Then I want to have those things available for title formatting but inside process_field() I only get a metadb_handle which seems to have no connection to any playlist (which is logical). I think I might be able to loop through the playlists and check by file path but that sounds cumbersome and I don't get the playlist number either.
The intention is to provide two additional titleformatting values called block_size and block_index. Each playlist is "grouped" according to specific fields (like artist + album). Each playlist entry with the same fields in succession then belongs to the same block and is provided with the index in the block and the block size.

Any tips would be appreciated.

I'm afraid that this is only possible when implemented directly in a playlist view as long as there is no such thing as a playlist_display_hook. Given just a metadb_handle it is impossible to determine which item on which playlist is currently formatted (there can be duplicate item in a playlist) or even if the item being formatted is on a playlist at all.

Two additional notes, not particularly about the problem at hand: Firtstly, when dealing with metadb_display_hooks, be careful about proper synchronization. A metadb_display_hook may be called from any thread, and while it is guaranteed by the caller that the metadb is locked during the call, it does not guarantee that the lock is held by the thread on which it is called. So it is safe to use the *_locked methods in metadb and metadb_handle, but you need additional locking for your private data. 0.9.5 makes increased use of multithreading on multi-CPU machines.

Secondly, the path alone is not sufficient to identify a particular track. You also have to compare the subsong index. The metadb guarantees that two handles with the same path and subsong are in fact represented by the same physical object, so you can compare metadb_handles by pointer value when testing.

That's probably the reason why noone has done such a component before :) (as it would greatly improve hybrid playlists imo). Well, too bad. Maybe some time in the future.