More > JRiver Media Center 28 for Linux
Smartlist duplicated thousands of times
mwillems:
I'm with zybex, definitely check the permissions on the files in "/config/.jriver/Media Center 28/Temp/Delta" and on the directory itself. It would also be interesting to know what the files in that directory were named.
Out of curiosity is the client machine also a linux machine or a windows machine? Are there network file shares in the mix and if so what kind? I ask because you mentioned changing the case of the smart list name, and I have sometimes seen strange behavior when changing case of filenames in a cross platform context because window is case insensitive and Linux is case sensitive. Some of the weirdness I've seen isn't necessarily something MC could do anything about (i.e. the issue was at the network share level so MC can't fix it), but I've also seen some odd behavior in MC too that I couldn't reproduce.
I'm not sure if smartlists are written out to files or only live in the database, but the case change might be a clue. If my hunch is correct, you might be able to reproduce the weird behavior by creating a smartlist on the same client, manually syncing changes to the server, and then changing its case, and syncing again.
merman-corrode-portage:
To be clear, I'm using the shiomax/jrivermc28 docker container, so I'm pretty sure all the dependancies, such as dbus-x11 are included, besides I noticed that error only appears when I'm using vnc to access the headless app so it's probably unrelated.
The files are all on the same machine as the jriver container with paths mapped to the container.
There are several client machines, however the particular one which made the edits to the smartlists is a Mac.
--- Code: ---# ls -la /config/.jriver/Media\ Center\ 28/Temp/Delta/
total 56
drwxr-xr-x 1 app app 492 Jul 6 13:53 .
drwxr-xr-x 1 app app 13426 Jul 7 11:15 ..
-rw-r--r-- 1 app app 574 Jul 6 13:53 browser.jmd
-rw-r--r-- 1 app app 38 Jul 6 13:53 'field (bookmark).jmd'
-rw-r--r-- 1 app app 41 Jul 6 13:53 'field (date last opened).jmd'
-rw-r--r-- 1 app app 162 Jul 6 13:53 'field (date tagged).jmd'
-rw-r--r-- 1 app app 34 Jul 6 13:53 'field (last skipped).jmd'
-rw-r--r-- 1 app app 2225 Jul 6 13:53 'field (library merge info).jmd'
-rw-r--r-- 1 app app 30 Jul 6 13:53 'field (skip count).jmd'
-rw-r--r-- 1 app app 38 Jul 6 13:53 'field (zone last opened).jmd'
-rw-r--r-- 1 app app 1485 Jul 6 13:53 mediafiles.jmd
-rw-r--r-- 1 app app 16 Jul 6 13:53 platform.jmd
-rw-r--r-- 1 app app 5228 Jul 6 13:53 playlistx.jmd
-rw-r--r-- 1 app app 16 Jul 6 13:53 removable.jmd
-rw-r--r-- 1 app app 283 Jul 6 13:53 user.jmd
--- End code ---
I performed the steps to attempt to reproduce the error but it seems to have synced all changes correctly.
EDIT: I noticed that the container default environment variable for GROUP_ID is set to 1000 where if I run "id me" on the host machine I get "id me
uid=1000(me) gid=100(users) groups=100(users)" so I added an -e flag to the container to modify GROUP_ID to 100. I'm not sure how to reproduce the error, but this could possibly have something to do with not being able to remove the Delta directory.
https://hub.docker.com/r/shiomax/jrivermc28
EDIT2: Prior to changing the environment variable for GROUP_ID, the "Delta" directory was still in my "Temp" directory.
--- Code: ---root@me-server:~# ls -la /mnt/user/appdata/jriver28-shiomax/.jriver/Media\ Center\ 28/Temp/Delta
total 152
drwxr-xr-x 1 me 1000 248 Jul 7 11:24 ./
drwxr-xr-x 1 me 1000 14576 Jul 7 11:29 ../
-rw-r--r-- 1 me 1000 574 Jul 7 11:24 browser.jmd
-rw-r--r-- 1 me 1000 1750 Jul 7 11:24 field\ (date\ tagged).jmd
-rw-r--r-- 1 me 1000 113178 Jul 7 11:24 field\ (library\ merge\ info).jmd
-rw-r--r-- 1 me 1000 547 Jul 7 11:24 mediafiles.jmd
-rw-r--r-- 1 me 1000 16 Jul 7 11:24 platform.jmd
-rw-r--r-- 1 me 1000 14926 Jul 7 11:24 playlistx.jmd
-rw-r--r-- 1 me 1000 16 Jul 7 11:24 removable.jmd
-rw-r--r-- 1 me 1000 283 Jul 7 11:24 user.jmd
--- End code ---
After changing the variable to 100 I get
--- Code: ---root@me-server:~# ls -la /mnt/user/appdata/jriver28-shiomax/.jriver/Media\ Center\ 28/Temp/Delta
/bin/ls: cannot access '/mnt/user/appdata/jriver28-shiomax/.jriver/Media Center 28/Temp/Delta': No such file or directory
--- End code ---
Looks like the app successfully removed it.
max096:
Honestly, setting the groupid should have changed nothing at all. The group has less access on the folders than the user going off your ls output. There is no additional access you should have gotten from adding the group.
Any chance you restarted the container? Because JRiver does seem to clear the temp dir when it restarts. You donīt even need to restart the container, you can just press the X (close) in VNC and it will get restarted too. Same result.
Not sure if JRiver is supposed to periodically clear the directory. I had a lot of files in there too.
--- Quote ---failed to commit changes to dconf
--- End quote ---
This happens when you open a file explorer inside the container. It opens nautilus and there is no gnome. Dconf is part of the gnome configuration system. Not totally sure what it wants to do with dconf. But I donīt see a reason why one would want to customize nautilus inside the container and it otherwise works fine. Just complains about it every time you open it.
merman-corrode-portage:
Fair enough, I noticed that the Delta folder appeared again shortly after, however the error has not popped up since. I'm now getting another error related to the Temp directory :-[
--- Code: ---mv: cannot move '/config/.jriver/Media Center 28/Temp/JR File Loader - 22418362717952 (10000) (10000) (79).dat' to '/config/.jriver/Media Center 28/Temp/Downloaded Images/Image.jpg': No such file or directory
--- End code ---
Navigation
[0] Message Index
[*] Previous page
Go to full version