Bugzilla – Bug 2028
Database cache fails to return loaded item
Last modified: 2008-09-15 14:36:01 UTC
SVN 4090 and later. There is currently a workaround implemented so it does not have any adverse effect, just a warning message. How to reproduce: - Using the CLI, issue "playlisttracks 0 3 playlist_id:XXX" where XXX is a valid playlist ID - issue "songinfo 0 10 track_id:YYY", where YYY is one of the tracks returned by above command - issue playlisttracks command again -> stderr will complain something like "Slim::Control::CLI::cli_songdata called with invalid object or path: ZZZ". playlisttracks calls $obj=$ds->objectForId('track', XXX) and then gets the tracks using $obj->tracks. It then iterates over the tracks and calls cli_pushSong, that expects either an object or a path. songinfo uses $track=$ds->objectForId('track', YYY). It seems that the second time, "$obj->tracks" fails to return an object for a valid track_id, but returns a scalar instead. cli_pushSong is given neither an object nor a path but a scalar corresponding to the track_id???. The current workaround is to try calling $ds->objectForId('track', ZZZ) with the bogus parameter and that works, but there is something very wrong, as it works nice on the first try! I tried d_sql but nothing is returned as I guess everything is cached. I am not sure which other parameters to try as DBI:... does not include that many debug messages. It may well be a bug in my code but I can't find it.
Fred - I'm unable to reproduce this. Any pointers?
Fred?
Created attachment 830 [details] Dumps of objects
Just tried it again on SVN4334. Same behaviour. I have attached a log that does a Dumper($thingy) at each step. At the end, while the code iterates over the tracks in the playlist (second call to playlisttracks), you can see that "for my $eachitem ($iterator- >slice(0, 2))" returns a SCALAR instead of a LightWeightTrack. If you check the log start, you can see that it does not behave this way on the first call. I am on MacOS 10.4.2. Except for the DB, I am not sure what else could be different...
Fred - a change I made today may fix this. Could you let me know? Thanks.
Yup, looks like it's fixed. I am leaving the workaround in for now...