PDA

View Full Version : Slim.exe 6.2b1 bld 3774 crashing on rescan of playlist



MrC
2005-08-04, 01:04
Slim.exe is crashing upon rescan of playlist.

Version: 6.2b1 - 3774 - Windows XP - EN - cp1252

Dan Sully
2005-08-04, 10:04
* MrC shaped the electrons to say...

>Slim.exe is crashing upon rescan of playlist.
>
>Version: 6.2b1 - 3774 - Windows XP - EN - cp1252

You're some days behind - this should be fixed in the latest nightly.

-D
--
<faisal> my life is collapsing to what will soon be NEGATIVE INTEGER degrees of separation.

MrC
2005-08-04, 10:17
I'm not sure what happened then, I downloaded and installed the 8-02 nightly, and the report was against that build. I'm downloading the 8-03 nightly now, and will report back.

max.spicer
2005-08-04, 10:37
I had this problem running the nightly that I downloaded at about 8:30pm last night (via svn). The server crashed every time I did a rescan. I sorted it by doing a "wipe cache" then a rescan.

Max


* MrC shaped the electrons to say...

>Slim.exe is crashing upon rescan of playlist.
>
>Version: 6.2b1 - 3774 - Windows XP - EN - cp1252

You're some days behind - this should be fixed in the latest nightly.

-D
--
<faisal> my life is collapsing to what will soon be NEGATIVE INTEGER degrees of separation.

MrC
2005-08-04, 10:38
Well, now I've updated to the 8-03 nightly. I'm getting asked to updated firmware (for the new WoL addition), so I know its the latest.

Still, the version shows on the web page under Settings shows:

SlimServer Version: 6.2b1 - 3774 - Windows XP - EN - cp1252

and there's no version in Properties for slim.exe. Where do I find the version? Perhaps the web page version needs to be updated with the nightly builds as well.

kdf
2005-08-04, 10:45
Quoting "max.spicer" <max.spicer.1t93gp (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I had this problem running the nightly that I downloaded at about 8:30pm
> last night (via svn). The server crashed every time I did a rescan. I
> sorted it by doing a "wipe cache" then a rescan.

"the server crashed" is fairly useless info, to be honest. Everyone loading up
nightly builds each day really should be making themselves aware of how to
check the logs/event viewer for more specific info. Any crash should create an
entry in the Windows Event Viewer (for those running the EXE). The rest need
to run command line and watch the terminal, or use the --logfile commandline
option. Even windows users might want to try this with the exe from time to
time if the event viewer doesn't happen to show any crash entry.

this would save a lot of "well, we fixed one possible crash, try it now"
reponses.

cheers,
kdf

MrC
2005-08-04, 12:26
Wow, hold on there Dick Tracy! :-)

There's nothing wrong whatsoever with simple "server crashed" reports iff the problem is trivial to reproduce as indicated. Its one thing if reproducing it is not obvious or reliable; its another when one trial produces the crash. Sorry, but I've been in the biz a *long* time, developing and debugging unix kernels or other higly complex software. To often developers push back to get "more information" when often much of that information is non-essential.

But since you asked, here's the info:



The description for Event ID ( 0 ) in Source ( Application ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Can't call method "id" on an undefined value at /PerlApp/Slim/DataStores/DBI/DBIStore.pm line 767.

This turns out to be the same as:

http://forums.slimdevices.com/showthread.php?t=15518

I did not catch that they were the same bug, as the version number reported in that bug vs. what I tought was the correct vresion number did not match (the one shown at the bottom of the Server Settings page are incorrect, and don't seem to change).

kdf
2005-08-04, 12:46
On 4-Aug-05, at 12:26 PM, MrC wrote:

>
> Wow, hold on there Dick Tracy! :-)
>
> There's nothing wrong whatsoever with simple "server crashed" reports

I didn't say it was wrong, I said it wasn't useful.
>
if you want to have something fixed, it is always better to provide
details. Otherwise all teh dev's are left guessing while ppl bark to
have things fixed, and bitch about the constant crashes. And I'm not
the only one getting tired to the moaning, and also having to repeat
the same requests for info every time.

>
> But since you asked, here's the info:
>
>>
>> The description for Event ID ( 0 ) in Source ( Application ) cannot be
>> found. The local computer may not have the necessary registry
>> information or message DLL files to display messages from a remote
>> computer. You may be able to use the /AUXSOURCE= flag to retrieve this
>> description; see Help and Support for details. The following
>> information is part of the event: Can't call method "id" on an
>> undefined value at /PerlApp/Slim/DataStores/DBI/DBIStore.pm line 767.
> .
cool, thanks. I believe this one should be fixed in the very latest.
line 1502 is another crasher, that is still there.

see, much easier with info.

-kdf

MrC
2005-08-04, 12:49
Yup, confirmed fixed.

Now how about an answer to where I get the version number for slim.exe ? Pretty Please?

kdf
2005-08-04, 13:00
Quoting MrC <MrC.1t99hc (AT) no-mx (DOT) forums.slimdevices.com>:

>
> Yup, confirmed fixed.
>
> Now how about an answer to where I get the version number for slim.exe
> ? Pretty Please?

that I don't know. Mine always says "trunk", which I believe is expected if you
run from teh svn checkouts. The answer for this could require a long look at
the build process for the exe downloads. Does this build number stick even if
you uninstall the previous nightly before installing the latest?

-kdf

Philip Meyer
2005-08-04, 13:16
>> Now how about an answer to where I get the version number for slim.exe
>> ? Pretty Please?
>
>that I don't know. Mine always says "trunk", which I believe is expected if you
>run from teh svn checkouts. The answer for this could require a long look at
>the build process for the exe downloads. Does this build number stick even if
>you uninstall the previous nightly before installing the latest?
>
I had this problem a couple of days ago, when I was trying to help resolve the rescan crash problem.

My build number seemed to get stuck on 3774, even though I had apparently downloaded and installed the latest nightly version, which had moved on to a newer number.

I uninstalled SlimServer and then reinstalled the latest, rather than install over the top. Now it simply says "6.2b1 - trunk". It would be useful if it could report the date that the nightly was built instead, so we have something better to report on.

Phil

kdf
2005-08-04, 13:48
Quoting Philip Meyer <slim (AT) hergest (DOT) demon.co.uk>:

> I uninstalled SlimServer and then reinstalled the latest, rather than install
> over the top. Now it simply says "6.2b1 - trunk". It would be useful if it
> could report the date that the nightly was built instead, so we have
> something better to report on.

Build number is actually far more accurate than date, if it can be fixed to work
reliably. Date wouldn't be applicable for those users not downloading an
actual build, and there are often several 'build numbers' skipped between
nightly builds; they actually correspond to the subversion change number.

As a bit of perspective:

given a date, I'd have to download the given nightly and install yet another
copy of the server (I have about 5 normally), or go looking through the
revisions for the right date, and the right cutoff for the nightly build. If
the times are close, then its a guess.

However, given a build number, I can simply update my test copy to that specific
revision (update will also go back revs) and test.

Quicker for me, means quicker for just about all of the other developer/hacker
types. What's in it for you? Quicker fixes :)

-kdf

MrC
2005-08-04, 14:33
Hmmm...


I didn't say it was wrong, I said it wasn't useful. if you want to have something fixed, it is always better to provide
details. Otherwise all teh dev's are left guessing while ppl bark to have things fixed, and bitch about the constant crashes.You're arguing over figures of speech - by "wrong" I meant and intended "isn't not useful". I think there were *sufficient* details (and that's the key) in my original report to discover the immediate cause through reproduction, and the other user who discovered the same problem was "seconding the motion." I'm all for helping out, and helping further the cause, but I think we need to keep something into perspective. I'm a paying customer working for free - you're a paid developer, probably with an equity position in the success of your company. Which of use should spend more time diagnosing? Hmmm.


Build number is actually far more accurate than date,
Every build number I've ever used has been a monotonically increasing number or sequence. It by definition cannot be "far more accurate" than a date when "the date" is actually a timestamp with necessary and sufficient precision. In fact, a date carries the additional temporal information for free.

I'm not saying you have to change anything, or complaining. However, you can certainly tag any/all files with a given timestamp (which is your build number when you build). This creates a working set, the collection of which is your build. Add a current timestamp tag when you want to rebuild, or add more tags to individual files as changes are made. Timestamps are far more useful that ill-defined, unmeaningful build numbers.

MrC
2005-08-04, 14:39
I had this problem a couple of days ago, when I was trying to help resolve the rescan crash problem.

My build number seemed to get stuck on 3774, even though I had apparently downloaded and installed the latest nightly version, which had moved on to a newer number.

I uninstalled SlimServer and then reinstalled the latest, rather than install over the top. Now it simply says "6.2b1 - trunk". It would be useful if it could report the date that the nightly was built instead, so we have something better to report on.

Phil
This is odd. There's a file called revision.txt which contains only the number 3774. Changing it seems to have no affect, so I suppose this file is included during the build, and not included at runtime. I could not find that number elsewhere in the entire directory of files. So it seems that some files are not being update when such a file exists already, or who knows what. But it unnerves me a bit that the build-package-install process is so fragile. They are just file replacements and deletions after all!

kdf
2005-08-04, 14:55
Quoting MrC <MrC.1t9ece (AT) no-mx (DOT) forums.slimdevices.com>:

>
> you're a paid
> developer, probably with an equity position in the success of your
> company. Which of use should spend more time diagnosing? Hmmm.

How wrong you are. No pay, no equity, my own free time. Now, feel free to
waste more of yours. I'll waste none of mine.

Suffice to say, if you really have such little interest in helping the
efficiency of development or the efforts of developers (paid or not), then I
really think you should refrain from claiming any knownledge as to what is more
useful information to developers.

-kdf

MrC
2005-08-04, 15:41
Quoting MrC <MrC.1t9ece (AT) no-mx (DOT) forums.slimdevices.com>:

>
> you're a paid
> developer, probably with an equity position in the success of your
> company. Which of use should spend more time diagnosing? Hmmm.

How wrong you are. No pay, no equity, my own free time. Now, feel free to waste more of yours. I'll waste none of mine.Retracted, and now informed.


Suffice to say, if you really have such little interest in helping the
efficiency of development or the efforts of developers (paid or not), then I
really think you should refrain from claiming any knownledge as to what is more
useful information to developers.

This was uncalled for, and a little misaligned with facts, given what I've already contributed to this forum in the short time I've been here (albeit, some mistakes too). And I think 25 years of being a developer on massive projects, and an independant software developer and consultant for the past 10 qualifies me enough. You can ignore my comments as you see fit, but that doesn't make them invalid. Look, I'm not asking you and others to change the current system. What I am hoping for is less of the pushback I feel on so many posts here. If feels like nothing's ever right or good enough. The My Way or the Highway attitude is not useful or productive. All voices, comments and criticisms are valid, and should be heard.

Dan Sully
2005-08-04, 16:09
* MrC shaped the electrons to say...

>feels like nothing's ever right or good enough. The My Way or the
>Highway attitude is not useful or productive. All voices, comments and
>criticisms are valid, and should be heard.

Funny that - I feel the same way. :/

-D
--
Off the record, on the QT, and very hush-hush.

kdf
2005-08-04, 16:28
Quoting MrC <MrC.1t9hl0 (AT) no-mx (DOT) forums.slimdevices.com>:


> This was uncalled for, and a little misaligned with facts, given what
> I've already contributed to this forum in the short time I've been here
> (albeit, some mistakes too).

Lets not tally up forum contributions, or mistakes. What I was asking for is
simple
information that helps get to the source faster. If users can, in general,
provide more specific info, then it takes a lot less of increasingly less
available free time. It is not a case of 'easy to reproduce'. In the case of
today's messages, I'm counting three different crashes caused by three
different problems, all during scan. At the time, only one was fixed. Now,
knowing the actual crash message would mean I could have then replied that it
was
already fixed. This would then result in a simple download and another user
happily enjoying music. Instead, it becomes a round of questions back and
forth, adding in the turnnaround time for each reply. Thus, you have a user
much longer deprived of music and the developer(s) spending more time to
basically discover that it is really just another case of the same bug, instead
of spending that time fixing the bug. To me, its simply being practical.

Also, bear in mind, I was asking this of the beta forum, not the beginners. I
expect that these are people with plenty of ability to provide a log or event
message.

> And I think 25 years of being a developer
> on massive projects, and an independant software developer and
> consultant for the past 10 qualifies me enough. You can ignore my
> comments as you see fit, but that doesn't make them invalid.

oddly, while it would save my time to ignore, I make it a point strictly to
never simply ignore. I respect that you have plenty of experience. I do not.
However, I have a lot more experience with the particular needs of this
project. I hope that you can respect that.

> Look, I'm
> not asking you and others to change the current system. What I am
> hoping for is less of the pushback I feel on so many posts here. If
> feels like nothing's ever right or good enough. The My Way or the
> Highway attitude is not useful or productive.

strange...I felt I was just offering information, trying to avoid the 'pushback'
reponses as well. I hate saying 'try it now'. I had hoped that etails of
innerworkings (ie many rev numbers in a given date), or information for
shortcutting crash reports would lead to faster fixes (my mistake). That has
very little to do with My way.

> All voices, comments and
> criticisms are valid, and should be heard.

correct me if I'm wrong, but all of this is still being heard. I distinctly
recall the feeling that my particular requests were being put down as invalid
simply becuase I was the seller.

I'm going to take a step back now, and get back to bug stomping. I humbly
suggest you consider the same, in whatever way you feel is best.

-kdf

Philip Meyer
2005-08-05, 01:13
>>Now it simply says "6.2b1 - trunk". It would be useful if it
>> could report the date that the nightly was built instead, so we have
>> something better to report on.
>
>Build number is actually far more accurate than date, if it can be fixed to work
>reliably. Date wouldn't be applicable for those users not downloading an
>actual build, and there are often several 'build numbers' skipped between
>nightly builds; they actually correspond to the subversion change number.

I think you misunderstood what I was saying ;-) The nightly SlimServer that I installed a couple of days ago is only reporting "6.2b1 - trunk" - my point was that there wasn't a build number or date to report on. Also, the one before that was reporting 3774, which was apparently wrong for the version I had installed. Maybe there was an installation problem, as I usually only install over the top, rather than uinstall the previous first.

As I wasn't trusting the build version, I was reporting the datestamp in the nightly. After installing a few nightlies, I may get confused which nightly I have actually got installed, so I think it would be nice to have both the nightly release date and build number reported.

After all, a build number doesn't mean much to end users (good for the developers), whereas the date is useful to the user as a check that the build has installed correctly.

Phil