Bug 3496 - track.bitrate being reset to 1bps as the track plays.
: track.bitrate being reset to 1bps as the track plays.
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.5b1
: PC Debian Linux
: P2 normal (vote)
: ---
Assigned To: Chris Owens
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-06 16:12 UTC by snarlydwarf
Modified: 2008-09-15 14:39 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description snarlydwarf 2006-06-06 16:12:17 UTC
My guess is this is in Source.pm:

2006-06-06 13:51:15.7870 Setting maxBitRate for Squeezeslave to: 64
2006-06-06 13:51:15.7875 Setting maxBitRate for Livingroom to: 0
2006-06-06 13:51:15.7909 SELECT me.id, me.url, me.content_type, me.title, me.titlesort, me.titlesearch, me.album, me.tracknum, me.timestamp, me.filesize, me.tag, me.disc, me.thumb, me.remote, me.audio, me.audio_size, me.audio_offset, me.year, me.secs, me.cover, me.vbr_scale, me.bitrate, me.samplerate, me.samplesize, me.channels, me.block_alignment, me.endian, me.bpm, me.tagversion, me.drm, me.moodlogic_id, me.moodlogic_mixable, me.musicmagic_mixable, me.musicbrainz_id, me.playcount, me.lastplayed, me.lossless, me.lyrics, me.rating, me.replay_gain, me.replay_peak FROM tracks me WHERE ( url = ? ) (
`file:///home/mp3/The%20Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3')
2006-06-06 13:51:15.8087 _checkValidity: Checking to see if file:///home/mp3/The%20Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3 has changed.
2006-06-06 13:51:15.8091 _hasChanged: Checking for [/home/mp3/The Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3] - size & timestamp.
2006-06-06 13:51:15.8526 undermax = 1, type = mp3, softsqueeze = 01:01:01:01:01:01

Note that the "undermax=1" is from the transcoding check, which already thinks this is a 1bps file.

2006-06-06 13:51:15.8881 _checkValidity: Checking to see iffile:///home/mp3/The%20Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3 has changed.
2006-06-06 13:51:15.8885 _hasChanged: Checking for [/home/mp3/The Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3] - size & timestamp.
2006-06-06 13:51:15.8893 Matched Format: mp3 Type: mp3 Command: - 
2006-06-06 13:51:15.8897 openSong: this is an mp3 file: file:///home/mp3/The%20Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3
2006-06-06 13:51:15.8901   file type: mp3 format: mp3 inrate: 0.001 maxRate: 64
2006-06-06 13:51:15.8904   command: -
2006-06-06 13:51:15.8909 openSong: opening file /home/mp3/The Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3
2006-06-06 13:51:15.8914 openSong: seeking in 2181 into /home/mp3/The Tubes/The_Tubes-T.R.A.S.H./03.Turn_Me_On.mp3
2006-06-06 13:51:15.8918 openSong: Streaming with format: mp3
2006-06-06 13:51:15.8934 UPDATE tracks SET bitrate = ?, lastplayed = ?, playcount = ? WHERE ( id = ? ) (`1', `1149627075', `1', `23391')

That last UPDATE is the killer... as it plays tracks it is wiping the bps on each track.  Note the d_source comment with "�nrate: 0.001" as well.  This was scanned correctly and in the database right until it played.

My guess is that this is a wayward inheritance in Player/Source.pm, specifically this line at 1371:
    my $rate    = ($track->bitrate(1) || 0) / 1000;

Why do I suspect that?  Because the intent is for that to use Slim/Schema/Track.pm, where the bitrate() function is defined, but inserting debugging statements in there shows that sub is never reached.  Something else is inheriting this and taking it as a request to set the bitrate.
Comment 1 Dan Sully 2006-06-09 14:56:27 UTC
Fixed in change 7854
Comment 2 snarlydwarf 2006-06-09 18:17:29 UTC
(In reply to comment #1)
> Fixed in change 7854

Yay!  Thanks, Dan, I'd say I owe you my first born, but I don't have one, and I'm not sure that would be a reward. :P