My songkong is installed on a ubuntu 20.04 server.
When selecting the Fix Songs option, it works great, scoops up the songs, moves them into my plex library.
I’m trying to cut out a step and use the Watch Folder, but nothing seems to happen when I do.
For information, the songkong is running in a VM which has folders from a NAS mounted to it via CIFS
Why is SongKong running in a VM, why can’t it now be installed directly on Ubuntu ?
Thanks for support files, I notice that for Fix Songs the album folders were within an overall discography folder, I wonder if that is problem.
Can you try just copying album folder directly to /unprocessed to see if that works
So I’ve got a proxmox ve(https://www.proxmox.com/en/proxmox-ve) cluster, and created a VM solely for Songkong and installed ubuntu 20.04, cifs-utils(to mount via cifs), java and songkong on it, nothing else. I run a bunch of services in VM - Songkong, plex, vpn, home assistant, pi-hole, they each are running on their own virtual ubuntu machine so they don’t interfere with each other and have static resources carved out for their sole use.
For the album folders, currently I’ve got 2 directly inside the watched folders, so not subfolders but the folders are directly under them. Not reading.
Is it possible that whatever technique that is being used to monitor, doesn’t register changes on folders mounted with CIFS(https://cifs.com) but rather the folders need to be directly on the host machine?
Just to be clear is the album folder added to the watch folder after starting watch folder task. It won’t work if the album folder is already there, even if you add new files to the folder after starting watch folder.
Yeah, that’s not what’s happening. These folders are dropping in after it’s already in watch mode.
Just an update here. Created a new folder, pointed the watch file there, and instead ran the shell script:
#!/bin/bash
mv /Landing/* /Unprocessed/
It moved the files over, but still no action from the watching songkong.
Okay, seems to be a problem with Watch Folder using web/remote mode. I tested on Windows in desktop mode and it worked fine, then switched to remote mode and didn’t work. Raised an issue, don’t know what the problem is yet but due to do a new release next week so a fix should make it for that release.
Actually Remote Mode on Windows is working after all, I will do some testing on linux platform.
You asked about could the problem be with remote folders, have you tried just copying a folder to a local folder?
I have tried on linux and it worked fine, but I have added some more debugging for next release so that if it still doesn’t work for you at least we can narrow down the problem
Just tried again with latest version, same issue. Moved folders to temp folder then back and nothing. Sent support files.
So is that a local folder or folder mounted with CIFS?
So the target folder(Unprocessed) is mounted. Tried with both a Temp folder on the NAS, which wasn’t mounted, then back to Unprocessed. And temp folder directly in VM and back to Unprocessed. Neither action was picked up.
Hi , got your report and it seemed that actually Watch Folder did trigger
However at same time you ran out of space on disk
26/11/2022 03.33.26:UTC:ServerFixSongs:setGenreOptions:SEVERE: No space left on device
java.io.IOException: No space left on device
at java.base/sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at java.base/sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:62)
at java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:132)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:97)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:67)
at java.base/sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:288)
at java.base/java.nio.channels.Channels.writeFullyImpl(Channels.java:74)
at java.base/java.nio.channels.Channels.writeFully(Channels.java:96)
at java.base/java.nio.channels.Channels$1.write(Channels.java:171)
at java.base/java.nio.file.Files.write(Files.java:3517)
at com.jthink.songkong.server.callback.ServerFixSongs.setGenreOptions(ServerFixSongs.java:586)
at com.jthink.songkong.server.callback.ServerFixSongs.saveOptions(ServerFixSongs.java:286)
at com.jthink.songkong.server.callback.ServerWatchSongs.startTask(ServerWatchSongs.java:82)
at com.jthink.songkong.server.CmdRemote.lambda$configureWebEndPoints$63(CmdRemote.java:171)
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:130)
at spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1568)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:530)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base/java.lang.Thread.run(Thread.java:833)
So that confuses things.
You are on Report 391 so I expect SongKong is using up a lot of space on its reports, so I would select Admin/Delete Reports to reclaim some space. Then retry the settings you have in report 391 to see if it works.