With different albums Audirvana Mac 3.5.29 shows certain tracks twice. These tracks miss album artwork or show wrong album artwork. The adempt to play such a track produces the feedback “No track could be found”.
Manual sync, integrity check and new indizes don´t change the problem.
Any ideas to solve the problem? Thank you.
1 Like
I’ve just noticed the same, unfortunately this is a serious bug.
The path reference in the database table ‘tracks’ seems to have changed, leaving a row with the old relative path behind, which results in a double. Where ‘Volumes/x’ was previously not part of the relative path, it now is; The change is good, but somehow old rows aren’t always (or ever?) updated or deleted properly in the conversion.
The easiest fix may well be to drop the library and add it again - but that’s if deleting a library now actually works. If not, delete the whole database and start from scratch… Or wait for D. & co. to release a fix.
1 Like
Playing a track converts it’s and it’s neighbours database entries to the new path format, but syncing the library uses old deeply relative paths and creates double records.
Hello Damien
I use an external USB harddisk. The itunes library file is on this harddisk.
In my case the double entries didn’t go away, how jannek discribed that in his post of Jan 13.
The behaviour of showing wrong or no artwork lead me to the question, where Audirvana gets the ID3 informations from. So I deleted the whole album in iTunes. It disapeered in Audirvana totaly. Then I reimported the whole album: same problem again with double entries. It seems, that there are old informations stored somewhere.
Same here; For Audirvana, I keep a copy on an external USB drive so I can take the whole library with me where ever I go (independent of the net); Mine is a 1 TB Sandisk Extreme Portable SSD with exFAT as the fs (I need it to be compatible with Mac/Win/linux).
Possibly important: I don’t use iTunes on my Mac, my library currently consists of one monitored folder.
It really seems that different parts of Audirvana now treat paths in conflicting ways.
That SSD is reasonably fast, scanning all 625 GB of FLAC’s from scratch isn’t such a big thing and I could well drop the whole database and start from zero - but I’d still rather just fix the paths with SQL. But… Can’t be fixed, the duplicates come back either way.
.
PS.
At least optionally, strictly relative paths would still be good; We could point the library to a symlink and have the data where ever, even switch it around easily. Mount from a NAS, connect a drive, no difference.
Also big on the library wish list: Multiple libraries and the ability to easily (temporarily) exclude them, and/or the same for monitored folders.
Thought I’d just revisit my situation as simply as possible…
- Only path configured in library: /Volumes/usbssd/flac
- Tracks before playing with 3.5.29 show path as: flac/collection/artist/album/track
- Start playing album, track path updates to: Volumes/usbssd/flac/collection/artist/album…
- Next two or so tracks are updated as well
- Hit sync in library settings -> duplicate tracks appear with the old path flac/collection/artist/album…
- The duplicates are not removed if played again, probably because the new path version of the track now already exists.
- Both “views” of the same track work, ie. can be played, so after a while, all tracks play twice…
Clearly, on-playback metadata checking updates the track path to a different one than the library scan does. Armed with all this, it shouldn’t be too hard to find the bug, which probably lurks in some change between 3.5.26 and 3.5.29, unless the sub-minor os update brought it up.
Let’s get dirty:
sqlite> .mode quote
sqlite> select t.album_id, a.parent_dev_uuid, a.parent_folder, t.location_dev_uuid, t.location_rel_path, t.location_type from tracks t left join albums a on t.album_id = a.album_id where location_rel_path like '%a_silver_mt_zion%' order by t.track_number ;
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/01-broken_chords_can_sing_a_little.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/01-broken_chords_can_sing_a_little.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/02-sit_in_the_middle_of_three_galloping_dogs.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/02-sit_in_the_middle_of_three_galloping_dogs.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/03-stumble_then_rise_on_some_awkward_morning.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/03-stumble_then_rise_on_some_awkward_morning.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/04-movie-never_made.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/04-movie-never_made.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/05-13_angels_standing_guard_around_the_side_of_your_bed.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/05-13_angels_standing_guard_around_the_side_of_your_bed.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/06-long_march_rocket_or_doomed_airliner.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/06-long_march_rocket_or_doomed_airliner.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/07-blown-out_joy_from_heavenas_mercied_hole.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/07-blown-out_joy_from_heavenas_mercied_hole.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','Volumes/jk_1TB_SSD/flac/jk/a_silver_mt_zion/he_has_left_us_alone/08-for_wanda.flac',1
9,'/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone','/dev/disk2s1','flac/jk/a_silver_mt_zion/he_has_left_us_alone/08-for_wanda.flac',1
sqlite>Hi @Antoine
Maybe something that is connected to that topic: If you choose an album Audirvana (german) shows the album artist in the artist field. If you choose a track Audirvana shows the composer (how the ID 3 tag is set) as the artist. The album artist, which in the german version is called misinterpretative artist too is correctly shown (but can’t be changed - why?)
Hello @Antoine
A next observation: if I close Audirvana and iTunes and then change the ID 3 tags with Yate, Audirvana is able to read all tags, included the grouping tag, correctly; No double tracks 
By the way iTunes does not read the grouping tag set with Yate.
So the change of ID 3 tags with both iTunes and Audirvana open produces double tracks, which don’t disapear with no means. Why?
Hello @Antoine
A next grouping tag observation: in this example only the 2nd track has a grouping tag, which is correctly displayed. In the line below the componist of the 3rd track is displayed even though there is no grouping tag used in the 3rd track.
I’m getting duplicate albums and duplicate tracks on a MacBook Pro running Catalina 10.15.2. My db is local as is my music collection, in my Music folders.
The more I try to fix it, by deleting my music folders and copying them back to my local drive, the more deeply entrenched the problem becomes. Audirvana is almost workable now with all the dupes. How do I drop the library? How do I delete the database? Will that help?
1 Like
Big text, but fast doing it… try this for duplicates.
If you have Playlists that are important export them first to desktop and save them in a folder… when Audirvana is reset, you can re-import them back in one shot. sadly to this day, the folders they were in if so, are not back, you have to do them again…
Before doing this, maybe you should not connect after deleting those files to Roon, Tidal or others… Install Audirvana alone with your database… if working, log to Roon or else after.
Apple hide the Home Folder in User Library at some time depending on OS System…
When you have clicked your Home Folder, and cannot see the Library Folder in there,
just do a ‘‘cmd J’’ to show the folder settings preferences and see at the bottom…
click Show Library Folder and then you’ll have access to the rest forever.
Delete your music folder(s) in your Audirvana preferences window with minus sign…
Close Audirvana.
Go to User… Home Folder… Library… Applications Support… Audirvana Folder…
Trash All the files in that folder (that is your database of music, back it up! or not).
Restart MAC.
Open Audirvana, choose a library music folder and LET IT GO, even better don’t try to adjust windows or edit files, even playing music while it is not finished… you’ll see the progress bar going… Could be long the first time depending on how large your library is, and MAC is fast or not… go to sleep if it is too long ! Then when sync is finished, shut down Audirvana, yes, close it before playing a song… that way, you will have your database new from scratch saved without crashing or with doubles.
Then copy the .sqlite file to somewhere else from that folder…
Home Folder… Library… Applications Support… Audirvana Folder…
as a backup in a folder like dated as today, then open Audirvana.
Now open Audirvana and play some music without doubles
Like that, if you enter a bug you can always close Audirvana, put the latest perfect backup .sqlite in the same folder, and restart mac, then Audirvana… you’ll be at that latest backup… if you have put something else there or edit songs in between, it will sync the new files, but you will only lose your play counts of those files played in between backups.
With the now obvious internal inconsistency of track path handling, I don’t think anything but a bugfix will help; Maybe try the previous version in the mean time, if someone has the installation package available. It might be useful to find out whether the errant behaviour started with an OS update or an Audirvana update.
1 Like
Still had a 3.5.26 package in my downloads so I tried with it, didn’t do anything to the database in between; Acts just like 3.5.29… So, something else.
#!/bin/ksh
DROP_PATH=$1
DATABASE=${2:-~/Library/Application Support/Audirvana/AudirvanaPlusDatabaseV2.sqlite}
typeset -i COUNT
typeset -i EC
[[ -z $DROP_PATH || $DROP_PATH == - ]] && DROP_PATH='Volumes/jk_1TB_SSD/'
[[ -f $DATABASE ]] || { print "Database file '$DATABASE' not found."; exit 1; }
print "Audirvana database: '$DATABASE'\nPath prefix to remove from tracks: '$DROP_PATH'"
COUNT=$(sqlite3 -bail "$DATABASE" "select count(track_id) from tracks where location_rel_path like '${DROP_PATH}%';")
EC=$?; case $EC in 0) ;; 5) print "Close Audirvana first."; exit 5;; *) exit $EC;; esac
(( COUNT )) && print "Tracks to update: $COUNT" || { print "No tracks to update, exiting."; exit 0; }
UPDATED=$(sqlite3 -bail "$DATABASE" <<__EOF
BEGIN;
DROP TRIGGER tracks_fts_update;
update tracks set location_rel_path=replace(location_rel_path,'${DROP_PATH}','') where location_rel_path like '${DROP_PATH}%';
CREATE TRIGGER tracks_fts_update AFTER UPDATE ON tracks BEGIN UPDATE tracks_fts SET title = new.title, grouping = new.grouping, album = get_album_title(new.album_id), artists = get_track_artists(new.track_id), composer = get_artist_name(new.composer_id) WHERE rowid = new.track_id; END;
COMMIT;
__EOF)
EC=$?; (( EC )) && print "FAILED." || print "Done!"
exit $ECI am also desperately waiting for a bugfix! I restarted from scratch many times but Audirvana keeps creating duplicates pretty fast for me. Many tracks I have 4, 5 times now. I made about 70 playlists and can’t afford to restart at this point.
The first thing to do is to export all those playlists first… (yes till now one at the time)
then you will have them saved somewhere on your mac forever… just right click one,
export press enter… next, next… in the same folder, then if you have to trash that database it will take you 5 secondes to imports them all back in Audirvana… while clicking the first in the open window dialogue then select with shift key the last one…
Now you know how to save your playlist… 70… 3 seconds each, not much time in your life…
Now do what i wrote up there… you’ll have it fresh database with no bugs or doubles, import playlists, place where you want them in order… sync if you want, do the three steps for optimizing database, close Audirvana and SAVE the new .sqlite file somewhere else on your mac for a backup of today…
Fine tips and all, but the SNR of this bug thread goes down with each workaround (mine included). There are issues with how Audirvana handles disks and paths, they need to be fixed.
For every track, Audirvana stores the file path in parts in the database; I suspect that either resolving the mount point fails while playing, or removing the mount point from the relative path fails or is done incorrectly - then the relative track path is updated to include Volumes/disk/.
In the tracks table, there are a few interesting columns:
start_frame = 0
last_frame = 158857020
length_frames = 158857020
location_bookmark = book�
location_dev_uuid = /dev/disk2s1
location_rel_path = flac/jk/mike_oldfield/amarok/01-amarok.flac
location_type = 1
file_type = FLAC
That location_bookmark is scary. Seems like Apple bookmarkdata; Makes me wonder what it’s for and how badly it can mess things up - are these necessary, couldn’t the app just simply use paths from the database?
Here is the uniqueness constraint for the tracks table (the “sum” of these columns needs to be different for each track row in the database):
UNIQUE(location_dev_uuid, location_rel_path, start_frame)
What Audirvana stores in location_dev_uuid as the identifier of a disk device is not an UUID, it’s a device node identifier (/dev/disk2s1); This may change any time you attach a disk - for example, attach two USB storage devices in a different order and they switch places. The device node is a totally useless bit of information.
Next is location_rel_path; this is supposed to be the file path after the mount point. Storing the track location this way saves a few bytes, but something fishy is happening here, this gets broken at playback, afterwards duplicate tracks appear.
Third is start_frame. In all of my tracks, this is zero; What was probably meant to be used is either last_frame or length_frames, which seems like a duplicate column (in my database it is, maybe not everywhere).
The uniqueness of a track row in the database is thus determined by:
- a volatile device node
- a relative file path, not anchored
- the static value zero
Then there’s the watched_folders table:
device_uuid = /dev/disk2s1
device_path = /dev/disk2s1
mount_point = /Volumes/jk_1TB_SSD
relative_path = flac
location_bookmark = book$
mount_point_bookmark = book�
Audirvana might use this table to find the audio files, but since I can play tracks with a location_rel_path like path/track and also those which have been updated to Volumes/disk/path/track, I guess it’s using tracks.location_bookmark instead.
There’s a relative_path column, but that bit of data is (also) stored in each and every track row as part of location_rel_path.
Again, the uniqueness constraint in the watched_folders table uses the device node as device_uuid. There’s a device_path too, containing the same data. - and those bookmark columns again.
The device nodes should be replaced with actual volume UUID’s (they’re strings like A16A32FC-2033-3824-80E4-08C2557696C0 and don’t change) to work as intended, or dropped in favour of a path-oriented design.
I’d lose all device related columns and the mount point information and just store the whole path to each and every track; Another option would be to just store the file name and use a folder table (id and full path) and refer to that in tracks and albums.
But, these are just ideas, what really needs to be found is what’s messing up the track paths while playing…
Hello
Thanks @jannek: “There are issues with how Audirvana handles disks and paths, they need to be fixed.”
I´m not a SQL specialist. But I try to find out, what triggers Audirvana to mess up the database.
Recently I found two new Audirvana problems with the database:
- Audirvana set my monitored folder more than once to offline - trigger is not clear for me. No possibility to put it back to auto sync mode. I had to delete the folder and add it again to the list. The consequence was, that all manual playlists were reset and showed 0 tracks. I reimported them from a backup. The smart playlists worked fine.
- The following action destroyed the whole database and damaged all my tracks by altering other ID 3 tags than I wanted
. Audirvana is unusable now .
Since I´m using Audirvana ID 3 “comments” field of almost all tracks began to contain weired number codes like A80F770B+297117+11+150+130250+155825+186425+200637+217360+221315+226590+248935+266680+285022. Yesterday I selected all tracks in Audirvana, cleared the comments field and saved that change. After that (see screenshots):
Instead of doing, what I wanted (the comments fields still contain numbercodes) Audirvana deleted the ID 3 tags “artwork”, “album” and “album artist” in all my over 5000 tracks. This is more than a hickup, this is a MCA, which causes hours of work for me.
- In the album view 6 albums are showed with over 5000 tracks
- In the track view the tracks are showed
- In the artist view the artists are showed without artwork
- Smartplaylists show 1 album
Don´t change ID3 tags with Audirvana to prevent such MCAs until the building and handling of the database is fixed.