Need to kill an entry in the DB (6.1.1)

[fathom39]

Please help. And, why doesn't SS have a delete option for each track in the left hand panel? Thank you.
================================================== ===========

BACKGROUND
- Library shows two tracks (titles spelled differently) yet they both point to same physical file.
- When playing album, track plays twice
- Am using 6.1.1

HAVE TRIED THESE, WITH NO SUCCESS
- 'Clear Libray Before Rescan', MANY times (never found Clear Cache'
- Uninstalled and reinstalled SS, twice
- Deleted physical track file, album folder, and artist folder
- Re-ripped & encoded using two different encoders
- Manually edited tag using three different programs

ACHIEVED SOME SUCCESS
- Nuked tag data, renamed physical file, let SS guess on rescan
- SS correctly guessed and created a new entry but old entry is still there. When I try to play it, the player reports "PROBLEM: CAN'T OPEN FILE FOR:" Ha! I tricked it! Makes me feel a little better :-)

[dean]

Need to kill an entry in the DB (6.1.1)

Is it possible that there's a playlist with a reference to the
missing file?

On Jul 23, 2005, at 9:41 AM, fathom39 wrote:

>
> Please help. And, why doesn't SS have a delete option for each
> track in
> the left hand panel? Thank you.
> ================================================== ===========
>
> BACKGROUND
> - Library shows two tracks (titles spelled differently) yet they both
> point to same physical file.
> - When playing album, track plays twice
> - Am using 6.1.1
>
> HAVE TRIED THESE, WITH NO SUCCESS
> - 'Clear Libray Before Rescan', MANY times (never found Clear Cache'
> - Uninstalled and reinstalled SS, twice
> - Deleted physical track file, album folder, and artist folder
> - Re-ripped & encoded using two different encoders
> - Manually edited tag using three different programs
>
> ACHIEVED SOME SUCCESS
> - Nuked tag data, renamed physical file, let SS guess on rescan
> - SS correctly guessed and created a new entry but old entry is still
> there. When I try to play it, the player reports "PROBLEM: CAN'T OPEN
> FILE FOR:" Ha! I tricked it! Makes me feel a little better :-)
>
>
> --
> fathom39
>

[JJZolx]

Please help. And, why doesn't SS have a delete option for each track in the left hand panel? Thank you.

Many would hope that this and a lot more interactive library management are planned in the future. It's the Slim Devices party line that this type of power isn't planned for SlimServer.

BACKGROUND
- Library shows two tracks (titles spelled differently) yet they both point to same physical file.
- When playing album, track plays twice
- Am using 6.1.1

HAVE TRIED THESE, WITH NO SUCCESS
- 'Clear Libray Before Rescan', MANY times (never found Clear Cache'
- Uninstalled and reinstalled SS, twice
- Deleted physical track file, album folder, and artist folder
- Re-ripped & encoded using two different encoders
- Manually edited tag using three different programs

ACHIEVED SOME SUCCESS
- Nuked tag data, renamed physical file, let SS guess on rescan
- SS correctly guessed and created a new entry but old entry is still there. When I try to play it, the player reports "PROBLEM: CAN'T OPEN FILE FOR:" Ha! I tricked it! Makes me feel a little better :-)

Don't rely on 'guessing' - use anally meticulous file tagging if you expect any kind of order to be made of your files.

Do you have any cue sheets in your music directory tree?

[fathom39]

Don't rely on 'guessing' - use anally meticulous file tagging if you expect any kind of order to be made of your files.

Do you have any cue sheets in your music directory tree?

Agreed, this is the first time I have ever guessed. I have spent many hours cleaning up Gracenote, freeDB, etc. entries. What does a 'cue sheet' look like? I have some playlists but don't think I have any cue sheets.

[fathom39]

Is it possible that there's a playlist with a reference to the
missing file?

Excellent, that fixed it. But ... why would an entry in a playlist back-populate to album contents?

[fathom39]

Excellent, that fixed it. But ... why would an entry in a playlist back-populate to album contents?

Nevermind, I just realized playlists should be kept in a folder separate from the music library.

[dean]

Re: Need to kill an entry in the DB (6.1.1)

Slimserver is a bit aggressive about gathering song information.
Users often have volumes that become unmounted and so we decided to
let references persist in the hopes that those files will come back.
(If we didn't, then the playlist would be missing tracks.)

On Jul 23, 2005, at 10:19 AM, fathom39 wrote:

>
> dean Wrote:
>
>> Is it possible that there's a playlist with a reference to the
>> missing file?
>>
>>
>
> Excellent, that fixed it. But ... why would an entry in a playlist
> back-populate to album contents?
>
>
> --
> fathom39
>

[rds]

dean wrote:

> Slimserver is a bit aggressive about
> gathering song information. Users often
> have volumes that become unmounted and
> so we decided to let references persist
> in the hopes that those files will come
> back.

Features like this are great, but they should be made available as options (e.g. 'Support removable media'). I'm sure the vast majority of users are using fixed media for their library, so a feature like this becomes more of a hindrance than a help.

Drastic changes in behavior need to be implemented cautiously and sparingly. For example, the new 'Browse Music Folder' and 'Browse Playlists' functions are so vastly different from previous versions (and severely broken, in my opinion) that they should have been presented as options. A key rule in software design is 'never take something away that was there before' (see http://forums.slimdevices.com/showthread.php?t=15260 for examples). In this case, instead of having to revert back to 6.0.2, I could have simply turned off the option to use the new browse functionality and still benefited from the other 6.1 enhancements/fixes. (Of course, if the updated browse functions provided the exact same capabilities as their previous counterparts but with the added performance benefits of the new code, you wouldn't need to present it as an option at all. How 6.1 made it out the door with these functions in their current form is somewhat puzzling.)

[dean]

Re: Need to kill an entry in the DB (6.1.1)

On Jul 24, 2005, at 8:08 AM, rds wrote:

>
> dean wrote:
>
>
>> Slimserver is a bit aggressive about
>> gathering song information. Users often
>> have volumes that become unmounted and
>> so we decided to let references persist
>> in the hopes that those files will come
>> back.
>>
>
> Features like this are great, but they should be made available as
> options (e.g. 'Support removable media'). I'm sure the vast
> majority of
> users are using fixed media for their library, so a feature like this
> becomes more of a hindrance than a help.
Only if something has gone wrong. If you delete music and then have
a playlist to play it, what should the behavior be?

Removable media isn't the only example. More common are USB/Firewire
drives that may have been turned off or network mounts that come and
go. This isn't a small issue, it's very common.

> Drastic changes in behavior need to be implemented cautiously and
> sparingly. For example, the new 'Browse Music Folder' and 'Browse
> Playlists' functions are so vastly different from previous versions
> (and severely broken, in my opinion) that they should have been
> presented as options.
We're trying our best here. The Browse Music Folder was severely
broken for many people in the old version. (It was nearly unusable
for me with a large top-level music directory.) The new
implementation was targetted towards the problems that folks were
complaining about, namely that Browse Music Folder should be fast.
And so it is.

Trouble is, to make it performant, we needed to change the display
format. Add to this that there are bugs that need to get fixed.

So, please post constructive feedback so we can make it better for
everybody.