Is there a way to disable random while adding items to playlist ?
It seems for the moment when you queue items while Xbmc being in random mode the items are added randomly in the playlist.
While this seems normal, this cause a problem when you want to add multiple items and start a specific one even if after the random should do it's part.
Since you no more have the correct item position
Since last posts about performances with thumbs from me and Millencolin007 where avoided based on the fact we where only talking about RPI that is slow by nature.
I've made more tests on my main XBMC machine : a dual core E8500 with 4GB ram running Windows 7 x86 on SSD. So not really a RPI and a slow machine.
The XBMC database contains :
- 3430 Albums
- 2920 Artists
- 18714 Songs
So a big but not too much database to have correct results, XBMC is in portable mode and of course database and thumbs cache are on the SSD.
The testing protocol :
I use Yatse on Galaxy S 3 as a viable and real use case test.
Yatse does batch queries of 500 items to get the data from XBMC for Albums and Songs but not Artists due to a now corrected bug in XXBMC mc but this permit to test if the limits in the query are in cause or not.
Of course Yatse does a little processing on it's side to insert in it's local database but the actions are the same with or without thumbs so the timings are meaningful even if not only the request time.
And now the results that talk by themselves :
The first query is shown and is repeated until end just by changing start and end.
1) without querying thumbs
Quote:2012-09-08 14:00:05.888 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioAlbums (3430)
2012-09-08 14:00:05.934 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetAlbums","params":{"limits":{"start":0,"end":500},"properties":["style","albumlabel","artistid","type","description","genre","title","artist","rating","year"]}}
2012-09-08 14:00:09.422 Warning/YatseLogger: Logger.Warning@177: End parsing AudioAlbums
Quote:2012-09-08 14:00:21.100 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioSongs (18714)
2012-09-08 14:00:21.234 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetSongs","params":{"limits":{"start":0,"end":500},"properties":["track","albumid","artistid","artist","duration","album","genre","title","year"]}}
2012-09-08 14:00:44.662 Warning/YatseLogger: Logger.Warning@177: End parsing AudioSongs
Quote:2012-09-08 14:04:00.800 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioArtists (2920)
2012-09-08 14:04:00.824 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetArtists","params":{"limits":{"start":0,"end":0},"properties":["style","description","born","yearsactive","died","genre"]}}
2012-09-08 14:04:02.305 Warning/YatseLogger: Logger.Warning@177: End parsing AudioArtists
Leading to timing :
Albums : 3.5 sec
Artists : 1.5 sec
Songs : 23.4 sec
2) with thumb field
Quote:2012-09-08 14:09:51.726 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioAlbums
2012-09-08 14:09:51.769 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetAlbums","params":{"limits":{"start":0,"end":500},"properties":["style","albumlabel","artistid","type","description","thumbnail","genre","title","artist","rating","year"]}}
2012-09-08 14:10:10.125 Warning/YatseLogger: Logger.Warning@177: End parsing AudioAlbums
Quote:2012-09-08 14:10:10.128 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioArtists
2012-09-08 14:10:10.185 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetArtists","params":{"limits":{"start":0,"end":0},"properties":["style","description","born","yearsactive","died","thumbnail","genre"]}}
2012-09-08 14:10:22.062 Warning/YatseLogger: Logger.Warning@177: End parsing AudioArtists
Quote:2012-09-08 14:10:22.330 Warning/YatseLogger: Logger.Warning@177: Start parsing AudioSongs
2012-09-08 14:10:22.484 Verbose/JsonRpc: JsonRpc.JsonRpcCallStream@152: Request : {"id":1,"jsonrpc":"2.0","method":"AudioLibrary.GetSongs","params":{"limits":{"start":0,"end":500},"properties":["track","albumid","artistid","artist","duration","album","thumbnail","genre","title","year"]}}
2012-09-08 14:11:58.222 Warning/YatseLogger: Logger.Warning@177: End parsing AudioSongs
Leading to timing :
Albums : 8.4 sec
Artists : 12 sec
Songs : 1m36 sec (96 sec)
I think the numbers are pretty clear that there is a problem somewhere I'll try to check Xbmc code and compile but well I'm no C expert at all and Xbmc code base is quite complicated
Ok so this is quite normal and I think some changes needs to be implemented.
Since there's multiple way to change current problem I prefer start talk here before changing things and propose PR.
The underlying problem is in CFileItemHandler::FillDetails this one is called for every items send back from JSON for single item or big lists.
One of the 4 case :
Code:
if (!item->HasThumbnail() && !fetchedArt && item->GetMusicInfoTag()->GetDatabaseId() > -1)
{
CMusicThumbLoader loader;
loader.FillLibraryArt(*item);
fetchedArt = true;
}
This function, if thumb or fanart is not present, will try to get it / generate it and while this
may be normal for Json functions like GetSongDetails it's a non sense for getting big lists.
Non sense for two reason : this is obviously not the correct place to do this, but much worse it will try every times so imagine 17000 songs without thumbs in mp3 or .jpg (same for artists/albums) then every time someone ask for songs all is rescanned to find new thumbs that still may not be there ...
The problem is way less visible for movies since most users have correct images or can generate image from movie for after first full scan.
The four solutions I see now are :
- Total removal of the fetching of art from Json queries
- Adds a parameter to CFileItemHandler::HandleFileItemList/CFileItemHandler::HandleFileItem and CFileItemHandler::FillDetails for fetching and settings this to true for XXXDetails and false for normal big listing.
- Add a new Json param for that in each queries that may return thumb/fanart for fetchingifmissing that default to false.
- Adds new Json commands to get / fetch thumbs / fanart for individual items like GetAlbumArts() ...
IMO solution 2 and 3 seems better.
The reason this has to be done in JSON-RPC is because of the changes jmarshall made to the texture cache. If a user opens XBMC after an update from Eden to Frodo and he doesn't enter any of his libraries there will be 0 artwork available. If he then uses a remote client using JSON-RPC to access his library he would get 0 artwork because the artwork is being cached whenever the item is retrieved for the first time. If that first time is through JSON-RPC we have to do it there.
I really have to disagree with your argument that it doesn't make sense to do this for a list but that it does make sense for GetFooDetails. Whatever property you request should be returned independent of whether it's GetList or GetFooDetails (same for actors etc in GetMovies). You always have the possibility as a client to not request the "thumbnail" and "fanart" property if you think it only makes sense for GetFooDetails anyway.
I agree that the current situation is anything but perfect because we try to grab artwork for items that simply don't have any artwork to be found and it is done on every request. But none of your solutions seem really feasable to me either. I don't like option 1 because it will provide inconsistent behaviour depending on whether the user has ever visited the library or not. Number 2 changes the behaviour of the returned data between GetList calls and GetFooDetails calls. Number 3 is probably the most hacky approach. Number 4 might be something that needs to be added at some time when there will be other artwork support like banners etc but I don't want to hack it in now and then have to change it again later and probably break backwards compatibility.
Unfortunately jmarshall is away for another week or two so he won't be able to state his opinion here. But I'll let him know that a problem exists.
I said may in bold to show that I was not thinking like that
The problem is not about requesting thumbs or not in Json list but fetching the data in Xbmc while the user just want to have the data if it present or not.
Even for first data get it does not seems reliable to do this scan from an synchronous http call, this would lead to timeouts.
When I did update the test machine and going in Audio I get a big popup warning telling me to scan thumbs or I won't get them, so the user is well aware that until he does that thumbs won't be present.
The current implementation to correct the fact that the user will eventually do Json first before going in interface have so many performance impact on 100% of the users (remember the 20 times ratio for RPI) that it can reach final stage.
If first access from JSON lock further generation of thumbs from interface I suppose this should be corrected
but if further access will correctly generate those then this is not really a problem.
I am trying to find out if a movie is in the xbmc database using jsonrpc. I'd like to use a filter using the field imdbnumber. I've tried other fields which work but imdbnumber doesn't seem to work. Am I doing something wrong?
Code:
'{"jsonrpc": "2.0", "id": 1, "method": "VideoLibrary.GetMovies", "params": { "filter": { "imdbnumber": "1259521" } } }'
In all the database I saw the imdbnumber is stored in database with the tt in front of it.
You should try "tt1259521".
(2012-09-09, 02:30)xsintill Wrote: [ -> ]I am trying to find out if a movie is in the xbmc database using jsonrpc. I'd like to use a filter using the field imdbnumber. I've tried other fields which work but imdbnumber doesn't seem to work. Am I doing something wrong?
Code:
'{"jsonrpc": "2.0", "id": 1, "method": "VideoLibrary.GetMovies", "params": { "filter": { "imdbnumber": "1259521" } } }'
Actually there is no simple nor advanced filter for "imdbnumber".
Is the simple or advanced filter for imdbnumber planned? For me it would be nice to have such a filter so i can decide to show a new download or hide it.
Nope it's not planned because it's not even available as a filtering option within XBMC itself.
With PVR in I saw you mentioned something about changing the JSONRPC PVR methods. Will that be internal as it were? Basically, is it worth targeting them as they are now or wait because they will change (params etc. is the main concern)?
Oh, and Addons next month?
Is there any plan to add the ability to install addons via the JSON API?
There are no PVR methods in JSON-RPC right now because I asked opdenkamp to remove them and provide them in a seperate PR. But from what I can tell we'll have to re-think the API and better integrate it into the existing Player namespace etc.
I've decided to remove the addons PR from the last milestone because I don't like the implementation of Addons.ExecuteAddon(). The others (GetAddons, GetAddonDetails and SetAddonEnabled) are pretty straightforward but not that useful without ExecuteAddon etc.
(2012-09-12, 21:24)Montellese Wrote: [ -> ]I've decided to remove the addons PR from the last milestone because I don't like the implementation of Addons.ExecuteAddon(). The others (GetAddons, GetAddonDetails and SetAddonEnabled) are pretty straightforward but not that useful without ExecuteAddon etc.
Ok, thanks for the update.