Rebuild Index takes forever
Beantwortet
BluOs: 4,2,10
Yesterday round 17:00 I started a Rebuild Index from my Windows Bluesound app.
The next day round 08:00 my Nas is still running and only 75.000 songs are processed (he has to process 220.00 songs)
Previous version only took some hours to do the job.
Was there something changed? Or is there a new option that I didn't see?
-
Seems that the "rebuild index" is making a loop and reindexing again and again after finding an error in one oof the music files.
This without any message or/and without a clear user report that gives an overview of the errors (and specially WHY some files are flagged as error).
Send support request was also failing because he could not find/contact the target destination...
0 -
Just received new software notification, upgrading player
0 -
How can I get the log as a file to attach it in the mail?
0 -
I remembered the : http://192.168.0.xxx/diag?print=1 command and did see that the reindex did fail on a file. (but , like before, no real reason why it did flag that file as failed)
But what was new for me that he did start again a rebuild/reindex, did fail again, and start again a reindex (and this on and on)
Is there no possibility that somebody customize a little bit the reindex perl to create a mail or report that shows in clear text:
- what file as the reason of the fail
- why this file not accepted by the reindex (because in Tag&Rename I did not see something special)
0 -
I had a similar issue back in january. My Node stopped indexing after upgrading to BluOs 4 because there was a file in my library that apparently is too big, even though there's nothing indicated about a maximum file size anywhere. This file also caused problems in BluOs 3 in that it didn't get indexed, but it did not cause the indexing to crash and make my Node unusable. I did finally find the file causing problems but support weren't helpful, and the logs did not indicate the cause of the problem. I did ask support to implement a function that tells the user which file causes indexing problems back then (february 22).
0 -
Hi Luc,
Surely the software has not been designed to fail indexing under certain conditions. So when it fails, this is unexpected behaviour, the software does not know why and cannot provide that information.
I have reported two bugs that were triggered by the contents in the metadata, fully reproducible, both remain unsolved to date. Merely say this to demonstrate that music files with entirely proper metadata apparently can cause failures in the operating of BluOS or its controller apps.
Like Seppi suggests, do report it to support, otherwise it will never get resolved.
In the meantime, consider renaming the offending music file to a non-music extension. E.g. offendingfile.flac renamed to offendingfile.flac.fail and try to reindex. If it fails again on another file, repeat the renaming on that file. It would actually be beneficial if it fails again, as that provides two (or more) offending files and one could try to find a common denominator.
These can be really silly things. In my cases this common denominator was some specific character (apostrophe or left parenthesis or right parenthesis) being present in specific metadata fields or all artist fields being the same for all tracks of an album that had an album artist defined.
Good luck!
1 -
Like the "index" function is written in Perl it is very important that every field evaluation is escaped correctly, else Perl is failing. This means that IF the index function is failing on a file that seems normal to music software (foobar or tag & rename) it's probably a software bug in your indexing Perl source.
Result is that we, end users, are responsible to solve the problem by renaming the file(s) because your software is failing without clear report or message.
I remember years ago the big problems the indexing had with a cd where we had track titles like:
- track1: !
- track2: !!
- track3: !!!
- track4: !!!!
... (I never had the chance to hear this cd via Bluesound)
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
7 Kommentare