Multi Text TAG not taken into account

[amatala]

Hi,

I have added the GROUPING TAG to the list of Multi text TAGs:

 

However, if I define a tree query based on GROUPING, the values are still grouped together:

 

 

I would expect to have separate tree entries for Live, Bootlegs & Compilations for example, not just one entry with all 3 values together.

If there is anything I am doing wrong, please let me know!

Thanks!

 

 

[Tiki]

Hello.

Thank you for the detailed explanation. I think what you did is right. So currently, I do not know why the results are not working.

I tried the same thing. It seems working as you expected. Any hints for you?

[amatala]

Thanks for the response… I have just tried the same thing…

I have placed GROUPING first in the list and added a new Test album with GROUPING containing 2 new values: Group01 and Group02 which are not used by any other album…

However, in my case it still kept them together:

 

So maybe there is something wrong in the GROUPING TAG of other files which causes it to break, but unfortunately I have no way of identifying such mistake, if it exists…
<div id=”ConnectiveDocSignExtentionInstalled” data-extension-version=”1.0.4″></div>

[amatala]

I have also tried with another TAG, ROONALBUMTAG which is also defined as Multi Text and which works fine in Roon (the multiple values are shown properly in Roon, so the data in the TAGs should be OK), but it’s the same problem also…

Maybe I should just delete the database and start over again with a clean situation?
<div id=”ConnectiveDocSignExtentionInstalled” data-extension-version=”1.0.4″></div>

[Tiki]

Hi, thank you for confirmation.

Umm…it is difficult to understand what is happening.

Are other multi-text tags being handled correctly ?

And … TuneBrowser will apply the value of a tag defined as a “multi-text tag” to the values updated since that definition. Values stored prior to that definition will not be applied (This behavior may be improved in the future). Does this behavior apply to your case ?

[amatala]

Album Artist is handled properly, I don’t have a problem there with multi-text values.

 

However any other custom tag is not OK.

If the multi-text property is only applied to newly updated values, I have tried adding a new multi-text TAG, not present in any file.

First I have defined TEST_GROUPING as multi text:

 

Then I have created a new Tree Query based on TEST_GROUPING:

 

After that I have restarted TuneBrowser, just to be sure, and I have imported a new test album including TEST_GROUPING for the first time in my library:

 

However the result was still not as expected even if these were brand new files, not stored before the change:

 

If there is anything else I could try, please let me know, I would gladly help in any way if I can.

[Tiki]

Hi,

Thank you very much for your trying, and your kind offer.

Please give me some time.

[Tiki]

I have released new preliminary version of the TuneBrowser.

This version is including some diagnostic codes and small bug fix for this strange behavior. Can you try this version when you have time?

Whether it works well or not, I want to check detail processing. So I would appreciate it if you could send me a dumpfile.

To send a dumpfile,
select a menu at the top of the TuneBrowser, “Help” – “Dumpfile” – “Generate dumpfile for inspection”.

Then, dialogbox will be shown to generate dumpfile, and please enter “the code” below:
0BAC-BBFC

This code is valid for 3 days. Please do not worry. If more than 3 days have passed and you need to get a new code, I can recreate it.

Thanks

[amatala]

Thank you for the quick response 🙂

I have generated and sent the dump file as instructed, but this new version already seems to be working fine without any change on my side:

 

I have now only 14 groups displayed instead of 45 before and RoonAlbumTAG is also working fine now.

I will do a few more checks to see if everything is fine, but at the first look the problem seems to be solved!

Thank you!

[Tiki]

Thank you for trying. I am so relieved that it worked!

The information in the dumpfile log you sent me also looks fine. The exact cause could not be determined, but it appears that the improved multi-text checks worked.

This topic will remain open for a while. If you have any findings about this matter, please post message here.

Thank you again.

[amatala]

Here is an update after a few more tests: It seems that adding new files or modifying existing files is causing the problem to come back. I have added a couple of new albums and the GROUPING is not working for those, but still OK for previous albums.

 

 

And the same goes for ROONALBUMTAG: modifying some existing files to add a new value to this TAG is causing the problem to occur again for those files but unchanged files are still OK.

 

 

So the fix seemed to be OK until I have started changing the existing multi-text TAGs by adding new values or modifying existing ones.

Attachments:

1. 

[Tiki]

Thank you very much for sending the follow-up report.

The results were not what I thought…

Can you send me the dumpfile as before? Please use the following code:

95ED-BD9C

[amatala]

I have generated a new dumpfile, but today the grouping is back to normal again… I have again 14 entries under GROUPING and not 15 like yesterday and ROONALBUMTAG is also normal again… Strange as I didn’t do any change since yesterday when it was wrong…

 

[amatala]

It looks like a restart it solving the issue now. Files which are detected as changed are first displayed incorrectly, for example I have ROONALBUMTAG entries which are not correct and 389 entries in total:

After restarting TB I have 382 entries and they are all correct now…

So maybe I should generate a new dump before restarting TB, when there are still incorrect entries displayed?

Anyway if restarting is fixing the issue, it’s still OK for me, I can do that after updates are finished.

[Tiki]

Thank you for sending dumpfile. No abnormalities were found.

By the way, how are you registering track into TuneBrowser? Is it a file, or is it from some UPnP-related network?

I would like to confirm the route that tracks are registered into the TuneBrowser in your environment. I was looking into the case of reading from files or editing on the TuneBrowser, but you are using tag named “Roon”. I’m not checking the route of network processing now. I would like to know if I should check that network route of registering process.

[amatala]

I am storing all my music files on a dedicated PC and they are accessible over a network share. There is also a uPnP server running there (Asset uPnP), but TuneBrowser is only importing the files from the network share listed as a music folder:

I often update my files from other programs like foobar2000 and periodically add more files to the library. When starting TuneBrowser it will automatically detect changes and scan new files added since the last start.

[Tiki]

Thank you for the detailed explanation.

I understood that the files are being read via the network. So, I have added a strict check of multi-text at reading function of FLAC and released it here.

To enable this function, please set following item to Yes (default is No):

– TreeItem: Tags
– Property: File access – Strict check of FLAC multi-text

And please send a dumpfile before restarting TuneBrowser, if you can.

The code is: 1681-1E01

I am very appreciative of your diligent response.
Thanks again.

[amatala]

OK, I have set the parameter File access – Strict check of FLAC multi-text and generated the dump file at a time where I had several wrong entries displayed for ROONALBUMTAG:

 

As always, after a restart of TuneBrowser, those entries were correct again, but as I generated the dump file before restarting, I hope the information in the file will help spot the error!

 

[Tiki]

I’m sorry but I could not determine the reason of this behavior from the dumpfile.

Can you send me a file that causes this behavior ? (File where ROONALBUMTAG values were not separated when first registered and were correctly separated after restarting TuneBrowser. I’d like to check if the same thing happens on the first registration to the TuneBrowser in my environment).

I will send an email to your registered email address with instructions on how to send (upload) the file. I will not use the files you send except for debugging purposes.

Thanks.

[amatala]

OK, I have sent a file from the album in the last screenshot above, which was wrongly displayed yesterday.

But in the end I have the same behavior with all files, if there are changes detected in multi-text TAGs, it’s first displayed incorrectly (grouped together) and then it is fine after restart. The only multi-text TAG which does not seem to have this problem is Album Artist, just like it was before.

Anyway, I am happy to help in any way I can of course, in the meantime I have the restart option which is solving the issue until more TAG updates happen.

[Tiki]

Thank you very much for sending a file. I think I finally found the cause.

The improvement made in the previous release was not wrong, but it was insufficient… Now I have released new version of the TuneBrowser here.

Please try this when you have time.

Thanks again for your help.

[amatala]

Everything looks fine now, new and updated files were properly displayed from the beginning, no restart needed. I will test more in the coming days and let you know if there are anymore issues, thank you also for the focus on this problem and the quick resolution.

[Tiki]

I am glad to hear that it seems to be working well.

It was your precise response that allowed me to focus on this issue and respond proactively. I thank you very much.

This topic will remain open for a while. I would wait your report.

[Tiki]

Hi,

Is the TuneBrowser working well about this matter ?

[amatala]

Yes, everything is OK now, I haven’t faced any issues after the fix, thank you very much!

[Tiki]

Thanks !

Now I close this topic and prepare to release this version as official.

[投稿者]

投稿