_logo.gif is never requested by any skin.
If you are going to toss out accusations, please make sure you know what you are talking about.

Try making sure that your cache is cleared, my guess is you've got some sort of bad state stuck in there.  A few quick refreshes should help.

b_next and b_delete should only be called from fishbone in 6.5 builds, so perhaps did you downgrade?

mute.gif should be present in the skin, so I have no idea why it should ever report that as missing.

please contact support@slimdevices.com for diagnosis.  All details so far point to a botched install, not a bug.

thanks

Defensive comments are not productive.  6.3.0 is not a quality release.  Everything about it says it was pushed out and not tested across all features, enough platforms and clients.  Now back to constructive bug commentary.

On my 6.3.0 install, everything was installed from scratch (as is each release I use). The existing Slimserver directory was renamed.  A new /usr/local/slimserver directory was created and the tar.gz file was expanded into that directory.   There was no downgrade.  dWhat I am using is taken directly from the distribution that I downloaded from the Slimdevices web page.

I've fixed this problem by renaming other graphic files to these names, however naive users won't figure that out.  They just won't go much further and will DUMP SLIMDEVICES for something else.  Do you want this?  A lot of alternative "turnkey" solutions are out there.  This is easy stuff to get right.

jumping to the coclusion of renaming graphics isn't much help either, I'm afraid.  I do this stuff for free.  Take my advice and contact support@slimdevices.com for diagnosis. You should not have had to rename any graphics.  As such, it is important to understand the state of your current install, and deal with the issue. Renaming might work, but it is not a fix.

KDF:  I agree that renaming isn't a fix, but it's going to be a really long wait for a stable release -- I won't run the nightlies anymore.  So this fixes it for me for now.

As for your "I do this stuff for free" comment.  Maybe it's about time you don't do it for free.   I think SD is making enough money to pay you for your efforts.   Seems weird to me that the 1st line of support at Slim Devices is the "pro-bono employee."

On the boards is a "sticky" post saying to please use the bug system and not post problems on the boards.  Now you say to contact "support@slimdevices.com".  Maybe instead of using the bug system, next time I'll make lots of noise on the forums that scares away legions of potential customers.

This last "release", your "burned out" attitude (at least that's what's coming across in these messages) and all these bug postings are all the signs of a good thing going bad.  A shame, really.   Take a step back and see how much "polish" has been removed from this product.

Please don't resport to threats.  I'm simply suggesting that this is a support problem.  support@slimdevices.com is the first line of support.  bugs.slimdevices.com is supposed to be a developer tool, as opposed to a support forum.  My opinion is that the stick is badly written. I'll certainly mention a slight change (much time is lost just digging to actually figure out IF there is any bug at all).

"burned out" might be a good term for it.  It has little to do with the product or the software.  It isn't personal, just a frank response, since you bring it up.

a tip, in case you are interested: avoid making a conclusion on a problem, unless you know for sure.  reporting an issue need only describe the problem, steps to reproduce, and mention any workaround that you may have noticed.  

I still think this is some sort of caching issue.  I'd have expected this from 6.5 (have seen it), but 6.3 should not be having that same problem, since it is not the same web code.  I'd still like to know if you can get things working right with a few quick refreshes, rather than renaming files.  If it is still a problem, please attach a copy of the source for the problem frame, right click and select view source (choose this frame, view frame source if using Firefox).

b_delete.gif, isn't called by the fishbone skin.  subtract.gif is.
d_next isn't called by the Fishbone skin, queue.gif is.

However, 6.5 builds do use b_delete.gif and b_next.gif in the Fishbone skin in order to share html code.  This is why I queried about downgrades.  

What did you rename to mute.gif?  That file should already be there; it is on my system.

I'm at a loss to explain _logo.gif.  That can only happen if the server isn't reporting a player model, which shouldn't happen since that particular section of html shouldn't load without a player. This specific graphic is why I'm linking this in my head to the other report, and a strangely missing client. That still doesn't quite line up, though.

If you are still interested in diagnosis, I'll await your results. Fishbone skin ends up being on my plate regardless.
thanks.

I have no quarrel with you KDF, I just frustrated that so much has gone wrong with this 6.3.0 release.  I stay away from nightly builds and betas to avoid this stuff, and I got hammered on so many bugs with the release.

I'm no expert at how the SS code works.  I just looked in the logs and renamed a few things I saw it wasn't finding.  Then I just wrote to the bug, the files I saw in the logs.

I regularly clear my cache, so not sure that's the solution either.  Little I can do now, because I got things to appear by creating the missing filenames.

I just wanted to advise the developers familiar with this system to keep an eye out for these issues.

ok, np.

Do you still have a copy of those logs?

Would you be able to describe the steps you took leading up to discovering the missing graphics?  ie...fresh install on new system (or after uninstall of 6.2.2), start service, open web to default skin, go into server settings -> choose fishbone, click the link to refresh/refreshed browse with reload button, etc.

Chris, or someone can use those steps to try to reproduce the problem.  Given the recent merges, I would guess that a 6.3.1 will be released (for bug 3650 if nothing else). Your other reports, aside from this and the dupes, go back well before 6.2.2 and have not been fixed becuase of their rarity/un-reproduceability (?).  Dumb luck that you ran into both only after installing 6.3.  Gut feeling is that the setup just needs some cleaning somewhere.  Java, template caches, etc.

Went back and had a look through the commit logs.  for reference, no part of the fishbone skin was changed between 6.2.2 and 6.3, and only a handful of the lower level EN skin files changed.  Of those, most are for handling rhapsody browsing. No graphic files were renamed, nor animals harmed in the making of this release.

I really don't see how anything could be wrong with the build itself.  I can only suggest that a plugin page is calling out for the b_delete and b_next graphics due to improper support for the skin.  6.5 HTML design is changed so that this kind of thing is less likely to happen.  skins have images with matching names.  this makes skin/plugin compatibility much simpler at the cost of a few caching issues yet to be worked out (aside from manual browser refresh)

Not sure what plugin would call for mute.gif, which is contained in the tar.gz (confirmed just now).  

_logo.gif has to be due to a missing player model, which as a best guess is related to the client assert backtrace.

As a post mortem, I would like to point out that 3 of four of these recent issues would seem to have nothing to do with the 6.3.0 release itself (2 being rare, known issues and this one being...outside of the scope...for lack of a better phrase), and that the QA team should not be slandered arbitrarily.  My attitude...remains a fair target :) I'm not sure how to proceed with this bug.  I can't see anything specific that can be fixed, but neither has this found an proven cause.  I'll leave this for Chris to sort that out.

This doesn't discount what surely seems to be a genuinely awkward user experience installing 6.3.0. 

You're probably right that the graphics are being called by plugins.  I didn't take note of where they happened, just looked at the logs and copied files in.  Next time I'll be more specific.

However, an important thing to note is that when SlimDevices readies a release, at the very least, it should review the various plugins that were compatible with previous releases and include problems seen in the release notes.   That way both plugin authors and slimserver users can see what issues are known and not file bug reports or brew frustration (as I've done).   I always review the notes and if I had seen an incompatibility or issue known about a popular plugin, I can pester the author to fix it.

*Bradley

So... is there a bug here? Or...?

Thanks

To my mind, the issue is dealt with.  Can always be reopened if the issue does crop up again.  I was unable to reproduce after several attempts at fresh installs and the user seems to be happy having done the edits.

Ok - we'll run with that then.

Bradley - please reopen if you see this again.

Thanks.