API startScan support
Damntry
Member
Another GPM pariah here 🖐️ Still testing before I make the full switch.
Are there any plans to implement startScan and getScanStatus on the API? I understand its a sensitive topic since it could get relatively abused, but it would also be very helpful.
Im planning on creating an app that, among other things, will update Astiga playlists automatically from local m3u/pls files without having to manually use the Import playlist function. This requires that the library is completely synced beforehand.
Usually this is hardly a problem since users will create custom playlists long after the songs themselves have been synced with astiga, but it will be useful for first time users with previously made playlists, plus my app will create automatic playlists based on the folder contents.
Basically, while hourly syncing is usually more than enough, I would like to ensure that the process works smoothly with no input, and that the user doesnt have to remember to re-do it a bit later once the sync is done.
Alternatively to startScan, a method to check the last hour at which the library was synced would work too, so I could pause once an "unsync" situation is detected, and then resume when the next automatic sync is made.
This could potentially be an upto ~59 min. wait time, excluding syncing times, but hey, the trade-offs of automation.
Also related, are there any limits on the API usage, particularly in the number of connections per minute or the like?
Comments
This requires that the library is completely synced beforehand.
Actually it doesn't. The playlist is stored as a combination of storage and path, so that means that the files do not have to be synced beforehand (or at all, syncing is optional) for them to work inside a playlist. Of course, it won't look as nice when the file is not synced before, as the metadata is missing, but it will work. The metadata will appear once the file is synced.
Also related, are there any limits on the API usage, particularly in the number of connections per minute or the like?
Yes, there is a limit of 100 requests per 10 seconds. So 10 requests per second with burst. However, you probably won't run into that, unless you have a very low timeout time, as it will basically stall/drop the SYN-ACK (so on TCP/IP-level, not HTTP-level), which will make every request 100n + 1 (n ≥ 1) seem very slow (but it should not require you to implement your own exponential back-off algorithm, as most Subsonic clients do not support that).
So, your main question: the main problem with syncing is that it is rather expensive. If you request your albums, then the server will work a bit, and return your album list within a second or two. If you request a sync, then the server may be busy for hours (or days), going through your music files and extracting the information from it. Hence the sync for free accounts is done manually. That way, only those actually using Astiga will use those resources, and not everyone who was once interested, set it up, and then forgot about it. Hence I am hesitant to add support for it at this point in time. Additionally, the startScan and getScanStatus used by Subsonic don't reflect the way syncing is done by Astiga (as syncing is done on a per-storage basis), which makes it more difficult.
So, your main question: the main problem with syncing is that it is rather expensive. If you request your albums, then the server will work a bit, and return your album list within a second or two. If you request a sync, then the server may be busy for hours (or days), going through your music files and extracting the information from it. Hence the sync for free accounts is done manually. That way, only those actually using Astiga will use those resources, and not everyone who was once interested, set it up, and then forgot about it. Hence I am hesitant to add support for it at this point in time.
Yeah I understand what you mean, which is why I mentioned it could be exploitable. I dont view this as that useful for free users, since there is a potential 3 day delay if it did require syncing and they often updated playlists and added new music, but for users that change things sparingly it does help them, so I get your point.
The playlist is stored as a combination of storage and path
That would be perfect. How would I go about that? The methods I see to add songs to playlists are "createPlaylist" and "updatePlaylist", which require a songID.
Non-synced files should also appear in the same list you get via getIndexes and getMusicDirectory, just with less information, but with ID.:
https://asti.ga/developers/#getindexes
I see now, thanks for the help.