SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Docker (arm32) not showing music folder tree in GUI

#1

As part of another issue, I installed the latest arm32 docker version of SomngKong on a Raspberry Pi. I have the container set up and running, but the remote folder I’ve specified in the /music parameter is not being displayed in the file tree:

c1
c11540×850 130 KB

However, if I open up a console session (via Portainer) into the running container, the remote folder has been mounted under /music, and I can navigate/see the contents.

c2
c21076×348 105 KB

It seems like perhaps a display issue or issue building the file tree in the GUI?

Support file generated for this thread.

#2

Hmm, I don’t know, but I’m away from office until Monday so won’t be able to check support files until then.

But I assume you have actually set a folder mapping to the docker virtual folder /music rather than just an actual folder called /music

#3

Yep! /music is mapped to Roon’s standard SMB guest share.

d1
d11750×858 91.2 KB

#4

Did a cursory examination of some of the logs, and see some errors that look like they are related to creating the folder tree view?

d1

#5

That looks like the issue, how many files in the folder?

#6

A fair number :slight_smile: . My Roon Library reports 117,000 tracks.

The Mac OS and Synology Docker versions handle that many tracks without any problems…does the arm32 version handle file counts/tree generation in a different way, or use a different variable type that can’t handle that many tracks? I’m running the arm32 version on a Pi4 with 8GB RAM and a 32GB SD card (with about 24GB free).

As a test, I re-mapped the /music share to a very small subset of my Roon Library (just two folders I want to use for watch folder monitoring, both of which are currently empty).

e1
e12032×302 71.1 KB

The same issue is occurring, and I still see the ‘Unable to count files in dir(2)’ error (but no warnings about value too large for defined data type).

e2
e21986×62 54.8 KB

#7

Quick update. Installed the intel image on docker running on an intel-based ubuntu machine, and the mapped /music folder shows as expected.

1
11086×862 99 KB

#8

Looked at your logs and had

java.nio.file.FileSystemException: /music: Value too large for defined data type
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
	at java.base/sun.nio.fs.UnixException.asIOException(UnixException.java:120)
	at java.base/sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.readNextEntry(UnixDirectoryStream.java:168)
	at java.base/sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.hasNext(UnixDirectoryStream.java:198)
	at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:348)
	at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
	at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
	at com.jthink.songkong.server.callback.ServerStart.returnStartPageContentsIfInvalidFolder(ServerStart.java:198)
	at com.jthink.songkong.server.callback.ServerStart.processRoute(ServerStart.java:225)
	at com.jthink.songkong.server.callback.ServerStart.processRoutes(ServerStart.java:342)
	at com.jthink.songkong.server.CmdRemote.lambda$configureWebEndPoints$19(CmdRemote.java:125)
	at spark.RouteImpl$1.handle(RouteImpl.java:72)
	at spark.http.matching.Routes.execute(Routes.java:61)
	at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:134)
	at spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1598)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.Server.handle(Server.java:516)
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)

Now searching this for error did bring up a an error with using buildx to build 32bit on 64bit system https://github.com/docker/buildx/issues/395 which is how we now build the arm32 docker build, so this may be the issue although arm32 build is working okay here so Im not quite sure at the moment.

#9

Raised https://jthink.atlassian.net/browse/SONGKONG-2622 to track this.