@xaviour wrote:
On an embedded device on the other hand, the transcoding is done almost in real time (oggdec uses about 80% of the CPU). So this strategy is probably reliable enough for embedded devices.
That’s interesting. Are you not using the ivorbis-tools package? The integer decoder should be much faster than that… I regularly do ogg transcoding on an underclocked slug using the integer decoder. The point is a good one, though — on a slow machine it may not prebuffer much.
Another angle is to postpone updating the playcount until a new request for a track comes. If the new request comes before the playtime of the track currently being played is elapsed, it means that the track has been skipped. Could someone from Roku tell me if the Soundbridge requests the next track before the current one has finished playing? Even in this case, it could be possible to mark a track as played if the track has been played for more than 50% of its duration (that’s what audioscrobbler uses for live updates if I am not mistaken).
That seems reasonable, but I don’t really keep any kind of session state. I try not to, anyway. So it would be hard to determine whose request was the next request. Particularly when there is more than one user updating it.
Yet another angle is to detect if the Soundbridge stops requesting the track (closes the HTTP connection?) before the transcoding process is finished. If do wonder what happens if the user pauses the track.
That’s what it tries to do right now, by using the served bytes length. I still think this might be both the easiest, and most close to accurate method to use.
Here is another question for the people of Roku. Does the Soundbridge close the HTTP connection if a track is paused? Ron, do you know what happen if the user skips a track? Does it mean that the Soundbridge close the HTTP connection and that “ws_writebinary” will fail at line 538 of “plugin.c”?
The soundbridge does close the connection on a pause, then seeks to the proper position on a play.
If a user skips a track, the soundbridge closes the connection and opens a new one. ws_writebinary fails, and the transcode function returns a bytecount smaller than the bytecount expected.
— Ron