can you recheck that you have a proper svn update.  in 3037, there is no 'can'
method being used at line 383.  This message has been mentioned before, and the
fix for it seems to be what I'm seeing at 383 now.

The fault, I believe was this line:
elsif (($item->can('moodlogic_mixable') && $item->moodlogic_mixable()) ||
$item->musicmagic_mixable()) {

which is now at 391.  You can confirm this by loading up
Slim/Buttons/BrowseDB.pm in your favourite text editor.

Looking at the file I don't see any reference to "can" at 383 in my local copy
and the updated reference is at line 391 as you state.  I've restarted dozens of
times...

Is this module cached somewhere or something because I can't for the life of me
figure out where it would be getting an old copy of the module.   There's no
other file on the system with that same name.

Here's what my line 383 looks like (probably the same as yours):

        if (!defined($item)) {
                return (undef, undef);
        }


Any clues?  Is that error message just bogus perhaps?  Any additional debug
flags I could set to elaborate?

Debian-x86 testing Linux distribution, btw.

I tried downloading the 4-22 nightly directly and have the exact same problem. 
Is it possible that the if/elseif/elseif is all being put together a single
statement on line 383 as far as the perl interpreter is concerned?  If so, that
would explain why it's listing lin 383 instead of 391 where the real reference
to "can" is.

are you using a startup script?  make sure that is pointing to the right copy of
slimserver.pl (I'm assuming you might have more than one, since I typically have
upwards of 5)

that if($item).. line is what should be preventing the crash.

The error message should be legit, and its not the kind that is typically
misleading.  I can't think of any debug flags that would help.  You could add
the following:

use Data::Dumper;
print Dumper($item); 

before line 383.  This will dump the structure of the list item to the terminal.
If you dont see that, then somehow slimserver is grabbing another copy of
BrowseDB.pm from somewhere.
  

I am using a startup script and I do have both the 60x branch and the 61 trunk
branches checked out, but it's pointing at the right location.  I added the
debug flags you suggested and got lots of output, this is the output when I
crashed it:

$VAR1 = bless( {
                 'titlesort' => 'COMFORT EAGLE',
                 'contributors' => 'CAKE',
                 'discc' => undef,
                 'artwork_path' => '2482',
                 'musicmagic_mixable' => undef,
                 'id' => '175',
                 'title' => 'Comfort Eagle',
                 'disc' => undef
               }, 'Slim::DataStores::DBI::Album' );
$VAR1 = \65;
Can't call method "can" on unblessed reference at
/home/tsandee/slimserver_svn/trunk/server/Slim/Buttons/BrowseDB.pm line 386.

Does that shed any light on what's going on?

looks like the error is stringing the if's together, and it looks like $item is
getting confused.  \65...any change your volume is around 65% ?

I guess what is happening here is the update loop for the browseDB mode is still
going, when volume lines interrupt and we're getting an overwrite of values.

yes volume is around 65% -- I think you're right!

The problem is that Input::Bar::lines() is being called without actually
changing modes in order to display the volume line for a short time.  Since it
does not change modes,Bar::Lines() executes the overlayRef for the current mode,
causing browsedbOverlay() to be run with improper values.

Here is the backtrace:

2005-04-22 15:13:01.8159 Backtrace:

   frame 0: Slim::Buttons::BrowseDB::browsedbOverlay
(D:/slim/server/Slim/Buttons/Input/List.pm line 168)
   frame 1: Slim::Buttons::Input::List::getExtVal
(D:/slim/server/Slim/Buttons/Input/Bar.pm line 150)
   frame 2: Slim::Buttons::Input::Bar::lines
(D:/slim/server/Slim/Display/Display.pm line 169)
   frame 3: Slim::Display::Display::mixerDisplay
(D:/slim/server/Slim/Buttons/Common.pm line 867)
   frame 4: Slim::Buttons::Common::mixer (D:/slim/server/Slim/Buttons/Common.pm
line 398)
   frame 5: Slim::Buttons::Common::__ANON__ (D:/slim/server/Slim/Hardware/IR.pm
line 616)
   frame 6: Slim::Hardware::IR::executeButton
(D:/slim/server/Slim/Control/Command.pm line 587)
   frame 7: Slim::Control::Command::execute (D:/slim/server/Slim/Hardware/IR.pm
line 640)
   frame 8: Slim::Hardware::IR::processCode (D:/slim/server/Slim/Hardware/IR.pm
line 455)
   frame 9: Slim::Hardware::IR::processIR
(D:/slim/server/Slim/Control/Command.pm line 587)
   frame 10: Slim::Control::Command::execute (D:/slim/server/Slim/Hardware/IR.pm
line 87)
   frame 11: Slim::Hardware::IR::idle (D:\slim\server\slimserver.pl line 599)
   frame 12: main::idle (D:\slim\server\slimserver.pl line 565)
   frame 13: main::main (D:\slim\server\slimserver.pl line 1141)

Can't call method "can" on unblessed reference at
D:/slim/server/Slim/Buttons/BrowseDB.pm line 386.

Created attachment 448 [details]
convert Bar::lines to use named args, and override overlay

The problem is being caused by an input mode line function being called from
outside its own mode.  thus the params for overlayRef are incorrect.  To make
it simple, add a $noOverlay param.  Making this, min, mid and max into named
args keeps it somewhat clean and won't require existing calls to change.

committed a fix in change 3045 for 6.1.  Awaiting confirmation before committing
to 6.0.2

works great, thanks kdf!

merged to 6.0.2 at change 3047.  marking as fixed

I'm guessing that the 6.0.x merge is innocuous. The bug only seemed to manifest
itself in 6.1 because of the BrowseID3->BrowseDB change.

true :)

but, since it changes how the one function is called, i figured it was best to
change anyway.  right now nothing uses it in 6.0.2 aside from Input::Bar, but it
certainly could happen

This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!