As titled states when attempting to use rename mask Yes if has metadata
Bug Generated 22 errors "Invalid File rename Mask either Artist/Title or Artist/Title please check your selected rename masks"
Your rename mask is
ifnotempty(artists_index[0],'/')
+ title
When you switch the Rename files based on metadata option from Yes if matched to release or song to Yes, if has metadata this allows it to to match files that have not been matched to MusicBrainz or Discogs. These songs are less likely to have the artists field that is referenced in the mask (because it is the special plural version of artist field), and this is causing the ifnotempty function to fail when it tries to check the length of the artists_index array because the array is not defined.
A few thoughts:
- Would be more helpful if the error message reported the file having the problem
- I thought the array was initialized to an empty array if we have no actual value
- Probably should modify the mask anyway to use artist field if no value for artists field
I will look into this further.
The value of artists_index is defined but if have no values for the artists field then it is defined as an array of length zero, which is maybe the issue.
String[] value = new String[0];
engine.put(fieldName.getScriptVar() + INDEX_SUBSTRING, value);
But for you if you modify the ifnotempty function that will prevent the problem occurring but then you will end up with some files not being put into an artist folder
function ifnotempty(value,sep){
return value!=undefined && value.length > 0 ? value + sep : '';
}
So instead
Modify ifnotempty2 to check for undefined
function ifnotempty2(value1,value2,sep){
return value1!=undefined && value1.length > 0 ? value1 + sep : value2!=undefined && value2.length > 0 ? value2 + sep:'' ;
}
and change Artist/Title mask to
ifnotempty2(artists_index[0],artist, '/')
+ title
That way if the artists field is empty it will fall back to the artist field
Actually this is better
ifnotempty2(indexValue(artists_index,0),artist, '/')
+ title
The problem is the artist_index index exists but artists_index[0] does not exist because for the problem files artist_index is an array of length 0. By using the indexValue() method we check the length of the artists_index array before trying to access an element of the array so there is no problem.
I cannot change the underlying code to create the artist_index with length of 1 instead of 0 because then functions that use length on an array would report 1 and it would that would lead to assumption that you have one value for the field when in reality have no values.
So solution is to use indexValue() when trying to access array values, and for completeness I will modify functions to check if they undefined
Great this worked very well. Only complaint I have using this " Yes if has metadata"
If an artist / artists doesn’t have a defined Album (Example Gravel Bath) Songkong doesn’t move the file. I would have liked if there is an artist / artists assigned then the file(s) get moved. If the Album field doesn’t exist or filled in then I would have liked Songkong to mark/add the field with [unknown]
You mean moved to a folder called [unknown] under the artist folder ?
Actually I dont get it because you dont put in album folders even if it does have an album, please give an example of what you would like.
If you look at one of the old reports I already submitted and look at Gravel Bath (for example) you see it is sitting in the folder labeled /music/__picard. Songkong did not move it out of that folder to /music/Gravel Bath (example) like I expected it would Since Artist and Song was defined in the meta data. I noticed all the remaining songs in that folder (__picard) had missing or not filled in Albums in the meta data field. To me it looks like if this field is missing or not filled in song doesn’t know what to do with it
Oh I see, its is because Yes if has metadata requires files to have a minimum set of metadata, and this includes album. Worth noting most users do want to put their songs in album folders not just artist folders.
You have two options:
- Use the Yes, for all files option - but this is not great for files with no metadata, you could run in preview mode first and see what files it effects.
- Based on your idea you could use the Auto Edit task to set all album fields to [unknown] if currently blank as follows
Enable Find and Replace on Basic tab
On Find and Replace tab:
- Set Select metadata fields to modify option to Album
- Set Match As to Match Regular Expression
- Set Find to ^$ (which denotes empty string in regex) it will then replace empty strings with the Replace value but will not modify fields with an existing value
- Set Replace to [unknown]
and select Start
Then if you run Rename Files again with Yes if has metadata it should now work with all files that have metadata but didn’t previously have a value for the album field.
I have run fix songs numerous times, and you can see from my example songkong added songkong_ID and AcoustID to the metadata to this song. So if songkong has ‘minimum’ requirements for it to be fully functional why isn’t it taken care of those minimums as well when I run fix songs?
I am talking about the Rename Files option being set to Yes if has metadata. I’m sayihg if you have the Rename Files option set to Yes if has metadata it will not rename files unless they have a minimal set of metadata, and this minimal set include a value for the album field. The point of this is if a file doesn’t have even have a value in the album field then it does not have very good metadata so it cannot be trusted to have correct metadata in any field, and so this option is protecting you from renaming files to a worse name due to poor metadata. If you wish to rename all files regardless of their metadata you can use the option Yes, for all files
“Worth noting most users do want to put their songs in album folders not just artist folders”
This is why I don’t want subfolders:
MusicBrainz:
Discogs:
It appears Discogs Capitalizes everything and since your software pulls from 2 data sources, I am left with multiply duplicated folders that Windows have issue accessing.
If I run songkong on my entire library I end up with 30+ artist folder that are unreachable and if I add album folder I have hundreds more and I have files that aren’t playable because of that case sensitivity. Songkong caused this issue, so I really don’t get why this software doesn’t have Case Insensitivity checks to prevent this.
You have options:
Use Windows compatible characters in filenames
Enable Maximum File Path Length
So why isn’t there a Case Insensitivity check done?
The issue with unreachable artists because have the same folder name except case is that you are running SongKong on Unraid Docker which is case sensitive and then using it on Windows which is case sensitive, so the obvious solution would have been to run it on Windows instead then this problem would not occur.
Although even then I can see that even if you were only on unix which is case sensitive you would not particulary want both a The Sisters of Mercy and The Sisters Of Mercy folders. Maybe because my main devlopment testing machine is Windows is the reason Im not seeing this. But this does not normally happen because if matched to MusicBrainz then Discogs will not overwrite fields but I suppose it could if it only matched to a Disocgs album and then you ran Rename Files it could then create the bad case artist folder.
Now also in our database we have links between Discogs artists and MusicBrainz artist so I thought that if you match an album only to Discogs but the artist is a known artist in MusicBrainz it will use the MusicBrainz name rather than the Discogs name but this doesnt seem to be the case, it does use the MusicBrainz sort name so if you look at the Sort Album Artist field it should say Sisters of Mercy, The
rather than Sisters Of Mercy, The
I could not find examples of The Sisters of Mercy or The Sisters Of Mercy or any other similar examples in the reports I already have from you so to get to the bottom of this would be useful if you run a Status Report and the Create Support Files.
So that is a fair point but the primary issue I suppose is that the album artist is different for the same artist depending on source, if the album artist was the same then when you ran Rename Files the corresponding folder name would also be the same.
But it would also be useful if even when the album artist was different (in case) (because maybe not matched to Disocgs or MusicBrainz but just had original metadata from other source) that if a version of folder already existed (except for case) that we used that rather than creating a new folder.
I have provided a few examples up to this point; Sisters of Mercy, Ace of base, etc…
So I have just sent you another report and here is what I did:
- I moved wumpscut to the __picard folder
- ran fix songs so songkong can make any necessary changes/updates/fixes
- ran rename files
- this is the output:
So as I already stated I don’t get why there isn’t a case insensitivity check to prevent this
Also as I have mentioned in the other thread I really don’t want to run the ‘windows’ version as the interface was glitching on me: you stated you couldn’t replicate it, and it took nearly 7 hours to process almost 1k files and it was slowing my network down. I don’t want to tie up 2 computers just to run this for that period of time.
So for the particular example of wumpscut actually the standard name is :wumpscut: on both Discogs and MusicBrainz, but on certain releases on MusicBrainz it is credited as :Wumpscut:
e.g
https://musicbrainz.org/release/b23277d0-116c-43ea-96ec-43793bf0170f
Note:
The (release) artist credit is :wumpscut:
The (track) artist credit is :Wumpscut:
The underlying artist the credit is linked to is :wumpscut:
e.g
https://musicbrainz.org/artist/e4e79264-c1ec-490c-b823-b2918204cd4f
Now in Fix Songs on the Format tab you have unchecked the Use standard Artist name instead of name displayed on cover option, if you renable this and rerun Fix Songs and then Rename Files this will resolve this issue because the standard name is consistent for both Discogs and MusicBrainz
In general it would make sense for you to keep this enabled because it will reduce the number of name variations and will resolve the issue for at least some of the other problematic artists. Could you retry and see how this goes.
As I said that is a fair request which I will consider, but the best solution would be to fix the metadata so it is consistent and then the filename problerm will go away. If we only fix the filename problem when you play your music it may still show the artist as two different artists because that will be using the metadata.
I couldnt replicate it myself, but another user had similar problem and I believe the issue to now be fixed by this issue and this was released as part of SongKong 11.3 on 21st of January. So would be grateful if you could give it a quick retest to see if it is resolved for you.
Fair enough, that is very slow and I expect mainly due to the music files being on the network unraid rather than windows local disk. It is best to run SongKong on the files locally, so for you I agree best to stick with Docker version.
Raised an issue for future consideration - https://jthink.atlassian.net/browse/SONGKONG-2716
But first step is to try modifying the Use standard Artist name instead of name displayed on cover option.