[narcan]

I just submitted a patch to allow files to be queued using SQL

http://trac.xbmc.org/ticket/4482

From ticket

Code:

Added support for adding files from the library to the playlist queue using SQL statements.

QueueMusicDatabase?

    * parameter = SQL Statement. Must only return one column, which is the path & filename to queue on the music playlist (0)

Example:

http://127.0.0.1:8080/xbmcCmds/xbmcHttp?command=QueueMusicDatabase&parameter=select%20strPath%20%20strFileName%20from%20songview

QueueVideoDatabase?

    * parameter = SQL Statement. Must only return one column, which is the path & filename to queue on the video playlist (1)

Example

http://127.0.0.1:8080/xbmcCmds/xbmcHttp?command=QueueVideoDatabase&parameter=select%20strPath%20%20strFileName%20from%20movieview

Reason for the patch is I'm currently writing a iTunes 'Remote' clone iPhone app for XBMC.

It uses the Library exclusively for grabbing the list of albums, artist, songs etc

I wanted to be able to support adding a large number of songs, but also adding them based on genre, composer etc.

Using AddToPlaylist was going to be much too inefficient here, so my preferred way was to have the server add the files based on an SQL statement..

[jmarshall]

Looks like a cool idea. It looks, however, like you're using it to just grab items from the db, so a more restricted version that handles the output side of the query might be more useful to make sure it's not misused.

I'm thinking just 2 parameters are necessary:

1. The item type (known for music ofcourse).
2. The where query.

The full query can then be constructed to make sure you get the full items etc as needed - you can use the Get*ByWhere() functions perhaps (they return full fileitems, but this may well be what you want in practice to ensure you have all the meta information available in the playlist?)

Cheers,
Jonathan

[narcan]

Looks like a cool idea. It looks, however, like you're using it to just grab items from the db, so a more restricted version that handles the output side of the query might be more useful to make sure it's not misused.

I'm thinking just 2 parameters are necessary:

1. The item type (known for music ofcourse).
2. The where query.

The full query can then be constructed to make sure you get the full items etc as needed - you can use the Get*ByWhere() functions perhaps (they return full fileitems, but this may well be what you want in practice to ensure you have all the meta information available in the playlist?)

Cheers,
Jonathan

The reasoning behind the Arbitrary SQL was that I was thinking there might be joins to other tables that would be necessary.

But in reality it looks like the views (musicview, movieview) etc have everything that you'd need.

I didn't even notice those Get*ByWhere() functions.

Now that you point it out it makes more sense and is more consistent to interface with these functions, I can then drop those GetListFromQuery functions I added (which I was a little dubious about anyway).

So if I added the type parameter maybe it should be reduced to one function ? Something like AddToPlayListFromDB ?

Also thinking I need shuffle support, which I'm thinking would best be supported some new HTTPApi methods. I guess simply SetShuffle(bool) and (bool)IsShuffled which would operate on a passed playlist..

Thanks for the help!

[jmarshall]

Sounds great

If you are only shuffling the ones you add you can ORDER BY random(). Otherwise, yeah, you'll have to add shuffling to the api if it's not already available.

Cheers,
Jonathan

[kraqh3d]

cool idea. the httpapi already has a means for arbitrary queries. if the intention of this function is for queuing to a playlist, then please restrict it so that only "proper" items get returned as jmarshall suggested.

regarding the shuffle... what do you want to do exactly? if you want to randomize the returned query then use jmarshalls suggestion. if you want to shuffle the playlist, then you can use the builtin function: playercontrol(random).

it affects the currently active playlist, and all builtins are accessible via the httpapi with "execbuiltin". (hmm, this should probably take its parameter as a url-encoded string.)

[narcan]

Ok I've added an updated patch to that ticket.

It's now only one function which is 'AddToPlayListFromDB'

type can be 'songs', 'movies', 'episodes' or 'musicvideos'. Used 'songs' instead of music to refer to what was actually being referred to here.

cool idea. the httpapi already has a means for arbitrary queries. if the intention of this function is for queuing to a playlist, then please restrict it so that only "proper" items get returned as jmarshall suggested.

Yep, I've been using this in my iPhone app to get the data to display. What I'm trying to add here is a corresponding way of queuing those items. Makes sense to use those existing methods.

regarding the shuffle... what do you want to do exactly? if you want to randomize the returned query then use jmarshalls suggestion. if you want to shuffle the playlist, then you can use the builtin function: playercontrol(random).

Yeah I think I want to be able to perform the shuffle on the playlist. This allows for shuffle to be turned on / off which matches the standard way the shuffle happens on the iPhone/iPod.

I was thinking of adding
- GetShuffle
- SetShuffle(bool)

As I need to be able to query on the shuffle status as well.

Didn't seem obvious to me that ExecBuiltIn was the right way to be calling this stuff. I guess I expected explicit methods to be there as they exist for play/next/prev etc. i

I also probably need control over the repeat as well. Which seems to also be available from ExecBuiltIn(XBMC.PlayerControl) though I also need to query on the repeat status as well.

What would actually benefit me the most is adding this information to GetCurrentlyPlaying in order to save on some hits to the webserver. Any objections to this ?

So to sum that up I guess I'd like to do the following
Add -

- GetShuffle
- SetShuffle(bool)
- GetRepeat
- SetRepeat('one'|'all'|'none')
- Add 'Repeat' and 'Shuffle' status to GetCurrentlyPlaying.

Thoughts ?

[jmarshall]

Sounds fine to me. I guess the point kraqh3d was making is that the setting of shuffling/repeat is already exposed (albeit not directly) to save the duplicating of code - you could drop it back down to that level I guess though.

Cheers,
Jonathan

[narcan]

Sounds fine to me. I guess the point kraqh3d was making is that the setting of shuffling/repeat is already exposed (albeit not directly) to save the duplicating of code - you could drop it back down to that level I guess though.

Cheers,
Jonathan

Ok no problem.

Yeah, thanks to kraqh3d for pointing that out, I had overlooked that.

I'll probably use that initially anyway as I'll be wanting to make the player work with the existing releases and features where possible.

It will have do some evaluation of the features and use what's available. So when queuing just one album it may make x number of calls to AddToPlayList if AddToPlayListFromDB is not available but for the larger queues you'll need AddToPlayListFromDB available in your build etc.

Once the current submitted patch is accepted and applied I'll submit a separate one for these other features.

[kraqh3d]

you can add an explicit methods too. "getshuffle" would be nice to return the status. then also include "getrepeat" for completeness.

here's what im thinking... update builtins as follows:

random() -- toggles shuffle on/off for the currently active playlist
random(on|off) -- explicitly sets the state for the active playlist
random(music|video) -- toggles shuffle on/off for the chosen playlist
random(music|video,on|off) -- explicitly sets the state for the chosen playlist

you can then define explicit httpapi methods that match this, but you can use the builtin on the backend to avoid the code duplication.

then for completeness, do the same for repeat:

repeat() -- cycles state for the current playlist
repeat(one|all|none) -- sets state for the current playlist
repeat(music|video) -- cycles state for the chosen playlist
repeat(music|video,one|all|none) -- sets state for the chosen playlist

likewise, a new setshuffle httpapi command can then tap into the builtin code.

(it sounds like a lot, but its not that much.)

** edit **

i just looked at the current builtin. the parameters for repeat are actually "repeatall", "repeatone", and "repeatoff". so as to not break anything, i'd leave that as is, but add "all", "one", "off" and "none" for easier usage.

[narcan]

I've actually already added these methods, just haven't submitted the patch yet.

I had added:

SetShuffle(1/0, playlist);
GetShuffle(playlist)
SetRepeat(all|one|none, playlist);
GetRepeat(playlist);

playlist is 0 (music) or 1 (music) like the other functions but will default to the current playlist if not provided.

Also added the following info to xbmcGetCurrentlyPlaying

Remaining: XX.XX
Shuffle: 1/0
Repeat: all|one|none

[narcan]

Err, sorry should have read that a bit closer. I overlooked that you were refering to the builtins.

But yep makes sense to update these with parameters as you suggest.

Also seems some of the terminology is a bit inconsistent, seems 'shuffle' is most widely used, but in this built in case it uses 'random'. Anyway, I called those new functions shuffle just because it seemed to be the most used word.

Cheers,
Dave.

[narcan]

Just noticed 'sho' set the milestone 9.04.

Does this suggest I won't see this change applied to the SVN until at least 8.04 is released ?

Guess I'd like to get a sense of when I could expect to see this approved/denied so I can make some decision as to what I need to support in my iphone app.

[jmarshall]

Correct - we are in a feature freeze, so until we officially branch for 8.04 it won't be added to SVN. Future freezes we hope to be shorter - this one's a planned long one so that we can get things as stable as we possibly can

Thus it isn't going to make the 8.10 release (which many will be using), so only those using SVN builds will be able to utilize your feature until 9.04.

Cheers,
Jonathan

[narcan]

Damn

Understand of course.

Still, wish I had of tried to get this in earlier. Nearly finished the iPhone app and not having this may reduce it working as slickly as Apple's 'Remote' app for iTunes, due to it being slow/limited when it comes to queuing files (only be able to queue say one album instead of all your music).

Anyway, looking forward to a stable release. Keep up the good work.

[jmarshall]

Can you add a folder directly to the queue (i.e. specifying the folder path, rather than the files themselves)?

If so, adding the musicdb url's directly might be useful as a workaround. Not as flexible as a general SQL query, but useful nonetheless?

If not, I for one would consider that a bug...

Cheers,
Jonathan