@twad wrote:
1. Add capability to read rss streams directly in scanner (maybe a feed downloaded by wget) – this would need a rss parser built into mt-daap and that seems like overkill.
And something that doesn’t belong inside the server, imho — it screams for a scripted solution, I think.
2. Add an intermediate format – as simple as a m3u, but where mt-daap accepted external urls and imported fields like artis and such without need to lookup external server, but rather used the information in the [/playlist.
Except this is not a one-time problem — there are other things that are very similar that could be done.
3. Extend the .url file scanner so I am able to import fields like artis, length, etc
That needs to be done anyway, to suport tag writeback.
At some point, we talked about a scripting interface that would allow someone to insert arbitrary info into the database. I saw it working something like this:
1. When scanning, when a server recognized a script (*.ffs – fireflyscript?) it would execute the script with a single argument: “index”. This would dump a list of items to be inserted into the database. The format would be something like:
fieldname vieldvalue
An “id” field would be the internal ID that the script recognized. So something like this:
id 1
artist some artist
album some album
item_kind 2
type .mp3
url http://some.server/song/whatever.mp3
bitrate 64
samplerate 44100
id 2
artist some other artist
...
The field names would be the same as the column names in the songs table, or the fields in the PMP3 structure.
When it came time to play one of those songs, then the firefly would execute the same script with two arguments, “stream” and the id of the song to stream. The script would dump the output to stdout.
That seemed like fairly flexible interface.
seem reasonable?