MinimServer Forum

Full Version: A lot of crash log files ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hello

I see that in MinimsServer folder, I have some crash files. I have about 45 of them, between january 22nd and yesterday, about 12k byte each.

They all seem to refer to the same issue :

MinimServer crash dump, produced at 20160304-202758.172

HTTPConnection: exception while processing HTTP request: com.minimstreamer.FLACResource$ReaderInterruptedException

com.minimstreamer.FLACResource$ReaderInterruptedException
at com.minimstreamer.FLACResource$Listener.processError(FLACResource.java:754)
at org.kc7bfi.jflac.FrameListeners.processError(FrameListeners.java:83)
at org.kc7bfi.jflac.FLACDecoder.readFrame(FLACDecoder.java:733)
at org.kc7bfi.jflac.FLACDecoder.readNextFrame(FLACDecoder.java:498)
at com.minimstreamer.FLACResource.readNextFrame(FLACResource.java:295)
at com.minimstreamer.FLACResource.open(FLACResource.java:222)
at com.minimserver.ServerRequestHandler.processRequest(ServerRequestHandler.java:39​4)
at org.jminim.lib.HTTPConnection$WriterThread.runWriterThread(HTTPConnection.java:4​63)
at org.jminim.lib.HTTPConnection$WriterThread.run(HTTPConnection.java:418)

Then a list of threads, some RUNNABLE, some WAITING

Is it normal ? If yes, can I delete those files ?
So far, minimserver seems to be running ok.

It is the last version (0.8.3 update 77) installed on a synology DS415Play.

Many thanks

Best
Thanks for letting me know about this. Please attach the most recent crash log file to a post here. Many thanks.
(05-03-2016 07:47)simoncn Wrote: [ -> ]Thanks for letting me know about this. Please attach the most recent crash log file to a post here. Many thanks.

Hello Simon

Thanks for you reply. Here is the last log file attached.

I don't know if it is correlated, but I have another weird thing happening to me.

I have created something like over 100 symbolic links, which are in a sh file.

All links are carefully checked. But sometimes it creates a side effect : some extra links are created inside a folder, which links to the same folder. And therefore the minimser rescan is very long because it loops on those internal links. Fortunatly there is a timer so it eventually stops, but of course the number of albums becomes huge (more than 9000 instead of 3000), because of those recurring links.

To give you an example, here is one of the weird behavior :
cd "/volume1/music/2) Baroque/Bach JS/_Vocal/#Cantates [Helmuth Rilling]/"
ln -s "../../#Edition Bachakademie 2000 [Helmut Rilling]/001 - Cantatas, BWV 1-3/" "Cantatas, BWV 1-3"

But then, inside the originating Folder "#Edition Bachakademie 2000 [Helmut Rilling]/001 - Cantatas, BWV 1-3/" I see that an extra link to itself has been generated which of course causes an infinite loop.

I have absolutly no idea of how those extra links have been generated. And it happened in many other places (I am tracking all of them now; painful jobs ;-))

Thanks for the help, and tell me if I have any things to perform.

Best

Serge
Hello Simon

sorry to bother again, but the situation is the following :

I have deleted all my symbolic links, the original ones and the looping ones.
I have rescaned the library.

My Music directory contains 4184 folder & 56719 files (which does include pdf, images, etc.), says the Synology.
But MinimServer, through both Lumin app (even after reload) on my ipad, & Linn Kazoo on my Mac, says 5560 Albums and 101870 items.

I see that in the album view, some albums are displayed 41 times instead of one (they are the albums concerned by the symlink; but again the symlink have been deleted)

I have no album which spans over multiple directories.
The difference seems quite big, right ?

Thanks
Best regards
(05-03-2016 10:14)lyapounov Wrote: [ -> ]I see that in the album view, some albums are displayed 41 times instead of one (they are the albums concerned by the symlink; but again the symlink have been deleted)

Try doing a full rescan. It might be that the symbolic links are causing problems with a normal rescan.

To do a full rescan, set the startupScan property to 'full' and click Rescan from the minim icon.
(05-03-2016 09:06)lyapounov Wrote: [ -> ]Thanks for you reply. Here is the last log file attached.

Thanks! The fix should be fairly simple and I will include it in the next version of MinimStreamer.

Quote:I don't know if it is correlated, but I have another weird thing happening to me.

I have created something like over 100 symbolic links, which are in a sh file.

All links are carefully checked. But sometimes it creates a side effect : some extra links are created inside a folder, which links to the same folder. And therefore the minimser rescan is very long because it loops on those internal links. Fortunatly there is a timer so it eventually stops, but of course the number of albums becomes huge (more than 9000 instead of 3000), because of those recurring links.

There is no timer in the MinimServer rescan. I would expect a looping symbolic link to cause the rescan to run forever.

Quote:To give you an example, here is one of the weird behavior :
cd "/volume1/music/2) Baroque/Bach JS/_Vocal/#Cantates [Helmuth Rilling]/"
ln -s "../../#Edition Bachakademie 2000 [Helmut Rilling]/001 - Cantatas, BWV 1-3/" "Cantatas, BWV 1-3"

But then, inside the originating Folder "#Edition Bachakademie 2000 [Helmut Rilling]/001 - Cantatas, BWV 1-3/" I see that an extra link to itself has been generated which of course causes an infinite loop.

I have absolutly no idea of how those extra links have been generated. And it happened in many other places (I am tracking all of them now; painful jobs ;-))

I don't understand this either.
Simon,

I have done the full rescan. Then I reloaded entirely the library on the iPad.

It has not changed : still 5560 Albums and 101870 items. But again, the issue is only in the album view. In the folder view I see only one instance of the problematic albums.

The only thing I can do is to unload minimserver app and databases, and restart from scratch ?

FYI this message happened again during full rescan. The file is 543M (10 minutes @ 24/192 bought on Qobuz :-)

FLACDecoder: FindSync LOST_SYNC: 0 at offset 10346046 in 6) Jazz/John Coltrane/Blue Train/1-Blue Train.flac
FLACDecoder: error at offset 19890176 in 6) Jazz/John Coltrane/Blue Train/1-Blue Train.flac
HTTPConnection: exception while processing HTTP request: com.minimstreamer.FLACResource$ReaderInterruptedException
com.minimstreamer.FLACResource$ReaderInterruptedException
at com.minimstreamer.FLACResource$Listener.processError(FLACResource.java:754)
at org.kc7bfi.jflac.FrameListeners.processError(FrameListeners.java:83)
at org.kc7bfi.jflac.FLACDecoder.readFrame(FLACDecoder.java:733)
at org.kc7bfi.jflac.FLACDecoder.readNextFrame(FLACDecoder.java:498)
at com.minimstreamer.FLACResource.readNextFrame(FLACResource.java:295)
at com.minimstreamer.FLACResource.open(FLACResource.java:222)
at com.minimserver.ServerRequestHandler.processRequest(ServerRequestHandler.java:39​4)
at org.jminim.lib.HTTPConnection$WriterThread.runWriterThread(HTTPConnection.java:4​63)
at org.jminim.lib.HTTPConnection$WriterThread.run(HTTPConnection.java:418)
*** Edit
When looking at the 060, there are a lot of symbolic links generated inside it (cf. picture)

So the problem is that my files have been bugged by generated symbolic links

It is therefore not a minimServer issue, but an issue with the extra symlink generated. What a mess !!

But here is the funny thing : I have deleted those 20+ symbolic links which were in only one directory; then ran scan

And the numbers have decreased from 5560 to 3160 albums, from 101870 to 52110 items; both being closer to the truth... only by deleting those links ???

Thx simon
******

A little deeper.
When looking at the minimserver logs, I see that it loops when there is a @eaDir (typical synology stuff)

001, 004 etc.. are problematic and there is a @eaDir
But then 017 021 etc. don't have a @eaDir scanned, and are not problematic

you see on the extract of log file that after 060 it scans again the 001 004 etc..
So it seems the issue is the @eaDir (and yes, it stops after a while; which means that there is somewhere a mechanism to prevent infinite loops)


Scanning directory #Edition Bachakademie 2000 [Helmut Rilling]
Scanning directory 001 - Cantatas, BWV 1-3
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 004 - Cantatas, BWV 10, 12-13
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 007 - Cantatas, BWV 21-22
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 011 - Cantatas, BWV 32-34
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 012 - Cantatas, BWV 35-37
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 014 - Cantatas, BWV 41-42
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 017 - Cantatas, BWV 49-52
Scanning directory 021 - Cantatas, BWV 65-67
Scanning directory 024 - Cantatas, BWV 75-76
Scanning directory 027 - Cantatas, BWV 83-86
Scanning directory 028 - Cantatas, BWV 87-90
Scanning directory 030 - Cantatas, BWV 94-96
Scanning directory 031 - Cantatas, BWV 97-99
Scanning directory 034 - Cantatas, BWV 106-108
Scanning directory 035 - Cantatas, BWV 109-111
Scanning directory 037 - Cantatas, BWV 115-117
Scanning directory 040 - Cantatas, BWV 126-129
Scanning directory 042 - Cantatas, BWV 133-135
Scanning directory 043 - Cantatas, BWV 136-139
Scanning directory 047 - Cantatas, BWV 152-155
Scanning directory 048 - Cantatas, BWV 156-159
Scanning directory 049 - Cantatas, BWV 161-164
Scanning directory 050 - Cantatas, BWV 165-168
Scanning directory 053 - Cantatas, BWV 176-178
Scanning directory 054 - Cantatas, BWV 179-181
Scanning directory 057 - Cantatas, BWV 188, 190-192
Scanning directory 060 - Cantatas, BWV 198-200
Scanning directory 001 - Cantatas, BWV 1-3
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 004 - Cantatas, BWV 10, 12-13
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 007 - Cantatas, BWV 21-22
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 011 - Cantatas, BWV 32-34
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 012 - Cantatas, BWV 35-37
Scanning directory @eaDir
Scanning directory folder.jpg
Scanning directory 014 - Cantatas, BWV 41-42
As you say, the problem is caused by the symbolic links from 060. The @eaDir folders shouldn't cause any problems for MinimServer. The rescan will ignore the contents of these folders because they don't contain any audio files.

Does 060 contain a symbolic link to itself? Your screenshot doesn't go far enough down to show whether or not there is such a link. If 060 does contain a symbolic link to itself, I would expect MinimServer to loop indefinitely during the rescan as there is no check in MinimServer to prevent this. I will try this myself to see what happens.
(06-03-2016 10:40)simoncn Wrote: [ -> ]As you say, the problem is caused by the symbolic links from 060. The @eaDir folders shouldn't cause any problems for MinimServer. The rescan will ignore the contents of these folders because they don't contain any audio files.

Does 060 contain a symbolic link to itself? Your screenshot doesn't go far enough down to show whether or not there is such a link. If 060 does contain a symbolic link to itself, I would expect MinimServer to loop indefinitely during the rescan as there is no check in MinimServer to prevent this. I will try this myself to see what happens.

Well I deleted all of them without looking for the internal loop. My guess is yes, because the number of tracks has been divided by two.

I have cleaned using find -type l and actually I had still 6 internal loops. Now should be OK

Thx
Serge
Pages: 1 2
Reference URL's