[narcan]

As I was looking to query by Genre, Years, Composers etc I didn't feel using the paths was going to really work for me.

But you suggestion of the musicdb I think will actually work really well.

I'm guessing it constrains me to only using the super types that XBMC defines (Genres, Artists, Albums, Years etc) but in practice this should do fine and in effect will mean it will end up mirroring XBMC's Library Mode view, which would make the most sense for consistency anyhow.

Just tried adding all artists to the queue by using

http://127.0.0.1:8080/xbmcCmds/xbmcHttp?...://2/;0;;1

and it worked great.

Thanks again!

BTW, where is the list of top level paths and their ID's defined ?

[jmarshall]

Awesome - we don't even have to semi-break the feature freeze

The top level paths are defined in the the "overview" directory nodes:

http://trac.xbmc.org/browser/branches/li...erview.cpp

http://trac.xbmc.org/browser/branches/li...erview.cpp

http://trac.xbmc.org/browser/branches/li...erview.cpp

http://trac.xbmc.org/browser/branches/li...erview.cpp

http://trac.xbmc.org/browser/branches/li...erview.cpp

URLs at lower levels are then derived from these in various ways - a -1 is used at any level to indicate "skip this level".

Cheers,
Jonathan

[kraqh3d]

i was suggesting to update the builtin for consistency. its easier for the httpapi command to invoke the built-in (although, hidden from the users perspective), than the other way around. and it provides consistency.

there's some history regarding "shuffle" and "random". they were two unique functions at one time. shuffle would alter the order, but it could be undone. random would leave the order intact, and play the items in a random order (without repeats until the entire list was played). and it was possible to have both enabled at the same time.

it may be beneficial to allow the use of "random" and "shuffle" interchangeably. shuffle is the only thing used in the gui now, so I would think it would be the preferable command.

** edit'ed a typo

** edit **

you can do more detailed queues using the db:// urls, but you need to know the url for the particular item which are based off the index value. (ie, to queue all songs by artist U2, etc.)

[narcan]

Awesome - we don't even have to semi-break the feature freeze

Also means it's pretty much backward compatible.

i was suggesting to update the builtin for consistency. its easier for the httpapi command to invoke the built-in (although, hidden from the users perspective), than the other way around. and it provides consistency.

Yep thanks, I got what you were getting at, I just didn't make that clear in my replies

you can do more detailed queues using the db:// urls, but you need to know the url for the particular item which are based off the index value. (ie, to queue all songs by artist U2, etc.)

Yep, think I've got things working pretty well now. I drive all my views via SQL queries so I've got all the ID's for the items. I implemented a class that I can push on paths with a value and type (artist, album, genre etc) and have it spit back either a where clause that will regenerate that info or the xxxdb:// path

Plus the queries it builds up seem to be smart enough to not do any more than is needed.

Now I'm just looking for a shuffle workaround Kinda annoying that it toggles rather than being able to explicitly set. If I had some way of finding out whether the current state was shuffled it would be fine. I can keep track of it to an extent in my app, but this state will be lost when it exists or invalidated when the user changes it. Any more creative ideas for a workaround here ?

Anyway, thanks again guys, it's coming along nicely now.

[jmarshall]

There's always more than one way to skin a cat:

Try requesting "playlist.random" or 392 via getsysteminfo or getsysteminfobyname.

It should return a (localized, unfortunately) string.

Not sure if there's a way to get general infomanager bools or not.

If there's not, there may well be a good argument that this is a bug in the API that you can set but not get

Cheers,
Jonathan

[narcan]

There's always more than one way to skin a cat:

Try requesting "playlist.random" or 392 via getsysteminfo or getsysteminfobyname.

It should return a (localized, unfortunately) string.

Not sure if there's a way to get general infomanager bools or not.

If there's not, there may well be a good argument that this is a bug in the API that you can set but not get

Cheers,
Jonathan

Cheers, that will work

Yeah, the localized string is a bit of a bugger but I'll just include the list of strings in order to support using the app with other languages.

Doesn't seem there is a way to get at the other values (bools, strings etc), looks like it only implements GetLabel for g_infoManager.

[kraqh3d]

Now I'm just looking for a shuffle workaround Kinda annoying that it toggles rather than being able to explicitly set. If I had some way of finding out whether the current state was shuffled it would be fine. I can keep track of it to an extent in my app, but this state will be lost when it exists or invalidated when the user changes it. Any more creative ideas for a workaround here ?

Of course you can get the current state:
bool bShuffleState = g_playlistPlayer.IsShuffled(PLAYLIST_MUSIC);

at least, i think thats right. if thats not right, it may be something like this is.
g_playlistPlayer.GetPlaylist(PLAYLIST_MUSIC).IsShuffled()

whatever, grep IsShuffled in the source, and you'll find it. so you can check the current state before explicitly setting it.

[jmarshall]

Sure, but that requires an addition to the API, which I believe we're trying to avoid at this point

[kraqh3d]

while your in there, if the shuffle() and unshuffle() functions do not check state first, please add that in there. (i hope its already in there, but right now I'm too tired to check.) something like this:

void CPlayList::Shuffle()
{
if (IsShuffled()) return;
// everything else remains the same.
..
}

void CPlayList::UnShuffle()
{
if (!IsShuffled()) return;
// everything else remains the same
..
}

[kraqh3d]

might as well do the patch right... stupid feature freeze.

[narcan]

Yeah as jmarshall pointed out at this point just trying to get by with what's available.

As soon as patches start getting accepted into the SVN I'm happy to make and submit the shuffle/repeat and other changes I've been mentioning.

Cheers,
Dave.

[sho]

There is no harm in submitting them now.
The devs are pretty busy, but someone might review it all the same if the moons align.

[kraqh3d]

oh sorry... i misunderstood. so you were asking if there was a way to get that from the httpapi as-is for app right now, not for your patch.

[jmarshall]

I consider any major hackery that you have to do on your side a bug in the API with respect to the shuffling, so that part of your patch may well be considered a bug fix.

So yeah - please post to the tracker, and as a team we'll decide whether it warrants a bug fix - we can always update the patch at a later time as you continue working on it

Cheers,
Jonathan

[jmarshall]

narcan: Do we still need to apply this patch or not - it's been quite a while (my apologies!) and it's unclear whether it was needed or not now?

Cheers,
Jonathan