Closed ik666 closed 3 years ago
Hi Igor,
I don't think we will get very far with a but report to LINN, their contorl points seem to work ok with their streamers, so they are unlikely to change.
It also seems to work ok with my setup.
How about if I add a config option, the default value is to calculate the bitrate as it is now, if the option is set to true the bit rate is calculated by multiplying by 125?
The option could be called something like 'BitRateCalculated'.
Cheers,
Pete.
Good idea, this seems to be the most flexible solution.
'BitRateCalculated' is fine, ... maybe 'ReportBitrateInBytesSec' would be more verbose ...
Hi Igor, I pushed a new version with the added option 'ReportBitrateInBytesSec'
Cheers,
Pete.
got it ... works as expected :) Thanks.
Hi Pete,
I've checked back with two content delivery server, how they encode and deliver the DIDL-Lite metadata to the control point:
the bitrate is 176400 : This is the maximum bitrate of the song in [bytes/s] -> 1.411,2 kbit/s = CD
the bitrate is 104000 : I encoded the FLAC file with enabled compression. Serviio seems to read and post the average bitrate of the song in [bytes/s] -> 832 kbit/s = it's still CD, but lossless compressed.
I believe most media server will implement the DIDL protocol according to the official documentation and encode the bitrate in [bytes/s].
If MediaPlayer wouldn't update the bitrate attribute with the instancious bitrate reported by MPD, MediaPlayer would first deliver to the control point a DIDL-Lite element the bitrate raw value meaning [bytes/s], after the update by MPD the unit changes to [kbit/s]. This is actually actually already the case (i.e. the first UPnP event has a reported bitrate of 176400, the following ones 1411.2). I think this behaviour is very counter intuitive.
Therefore I would suggest to report the UPnP bitrate in bytes/s and optionally file a bug report to LINN? What do you think?
Cheers
Igor