Is it possible to have a couple of songs that are referenced '0' times? Doesn't seem possible I would think that at least a '1' would be required, yes the songs do play so they are physically on the disk.

If they're "unattached" in old carplayer parlence, then they will have refs=0. They are in the soup, and you can play them with search on the carplayer, but they don't exist in any playlist at all.

Hugo

Refs=0 means that they're not in any playlists. You can still use "search" to find them on the player, but they have been deleted from all playlists (or have never been added to a playlist in the first place).

Remember that it is possible (in 2.0 and later) to delete an item from a playlist without deleting it from the player. Back in the 1.0x days, deleting it from the last playlist was supposed to delete it from the player, so refs=0 usually meant something went wonky. Now it's a normal thing.

If they're "unattached" in old carplayer parlence, then they will have refs=0. They are in the soup, and you can play them with search on the carplayer, but they don't exist in any playlist at all.

The odd thing is the particular songs are in at least 2 other playlists, besides the album they are under they also appear in my 'new' playlist and 'favorites'. I would think that a min. of 2 references would be attached to them.

OK I guess the songs were not in another playlist it was another version of the same song that was in other playlists.
So I take it if it's referenced=0 then it's only in one playlist the original playlist.

If refs=0 then the song isn't in ANY playlist at all. If you have other versions of the song in playlists then you might want to delete the unattached version.

Rob

OK if a song is listed in 'All tracks' and no where else then it's considered unattached?
So I copied the 'unattached' song into the playlist it should've been in and all is well right? No problems doing that right?
I know the best way would be to re-upload the file but I can't the original is gone.

OK if a song is listed in 'All tracks' and no where else then it's considered unattached?

I think you mean "if a song is listed in all tracks but not in a playlist". See, if it's in All Tracks, and you've got your tags filled out, then it probably also appears in Years, Artists, Albums, and Generes. Those are the "soup" views, automatically built from the song's tags, and they are not related to the REFS count.

If that's what you meant, then yes. When the song is listed in one of the "soup" views but not in a playlist, that's when it's considered unattached and its REFS count should be zero.

So I copied the 'unattached' song into the playlist it should've been in and all is well right? No problems doing that right?

Right. You've now given a homeless song a home.

I know the best way would be to re-upload the file but I can't the original is gone.

No, the best way would NOT have been to re-upload. If you had done that, then you would have had two different copies of the song on the player's hard disk. You did the correct thing.

Thanks!

See, if it's in All Tracks, and you've got your tags filled out, then it probably also appears in Years, Artists, Albums, and Generes

Actually a song will be listed, as far as I can tell, in all soup views regardless of tag data. It will just be listed under the "none" branch of each view if that tag is missing. Which is great for finding tracks that are missing tag data (or have things like years set to "0" or other invalid values).

Bruno

Yeah, what he said. Also, in beta7, you can edit the leaf branches in the soup tree to do a bulk tag. Anybody notice that yet?

Actually, yeah. When I did it, it seemed like the "natural" thing to do. Because it worked so well and so transparently, I didn't realize it was a newly-added feature. Cool.

I had to throw away 80-90 lines of code to make that work .

In that case your task next week is to throw out another 10,000 lines of code - we'll have the most featureful application in history!

Rob

BTW, when in dilemma like this, add FID to displayed columns. That way you will easily see it two occurences of a tune are links or indeed separate tunes.

I can only assume 2 FID's would be the same e.g. ba0 & ba0?
I don't really know what a FID is, I've seen it mentioned here once in awhile, I'm guessing it's a songs unique ID number?

The FID is the FILE ID, the actual file name of the MP3 as it is stored on the hard disk.

There is a corresponding FID for the song's database tag entry. It is the same file name as the song's FID except it ends in a 1 instead of a 0. More information on this subject can be found at the Developer section of www.riocar.org.

More information on this subject can be found at the Developer section of www.riocar.org.

I checked there first but it still left me wondering how to actually check to see if a song is actually on the player twice if there is any duplicates since FID column gives a different FID even if a song is in there twice. Since the 'all tracks' view can't tell you in what particular playlist a song is referenced but rather how many times it is referenced. I guess it is a wish for me that 'all tracks could tell you in what playlist the original song is located & it's copies in others. Maybe I have too many copies of a song in other playlists a majority of my songs have as many as 10-11 'refs'.

gives a different FID even if a song is in there twice

That's because the song is in there twice -- there are two copies of the song. If you had referenced a single song from multiple playlists, then there'd only be a single FID.

'all tracks could tell you in what playlist the original song is located & it's copies in others

It doesn't work that way - there's no concept of 'home' playlist for a song. There's no directory structure on the data partition(s) of the empegs disk(s), all tunes are just tossed into one big pile. Then the file name/number (FID) is entered (or not, then you have a tune with refs=0) into one or more playlist. All playlist are, in this way, equal -- no playlist is given any special treatment just because it was there you initially dropped the file in emplode.

One way of spotting duplicates is to goto All Titles, sort on Title, add the FID column (under the View -> Columns...) Now, any two lines with the same Title and Artist are suspect (but not automatically duplicates, as it could be different versions...)

Another way is to export the DB to CSV, import into a database and make a join query on the table with itself, somethig like this:
SELECT Empeg.Artist, Empeg.Title, Empeg.FID
FROM Empeg, Empeg AS Empeg_1
WHERE Empeg.Artist = Empeg_1.Artist
AND Empeg.Title = Empeg_1.Title
AND Empeg.FID <> Empeg_1.FID;

Anything returned has identical Title and Artist but different FIDs - suspected duplicates. Add more fields (like duration, length etc) to easier/more certain spot duplicates, both to display and in the query itself...

/Michael