Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[max096]

I just wanted to share this with you guys. i made my own docker image now that I wanted to do for quite a while, but had a few problems along the way.
However, now it's fully working (I think).

You can find the source here (and description on how to use it and so forth): https://gitlab.shio.at/max/jrivermc25-docker
And the dockerhub: https://hub.docker.com/r/shiomax/jrivermc25

It's based on https://github.com/jlesage/docker-baseimage-gui and as such comes with the same webgui all his docker images use to use as an alternative to a VNC client. You can still use a VNC client with it. But I mostly won't anymore.

The only other public image for jrivermc25 currently seems to be one built by jatzoo (been using his 24 image before). I first thought this one would come out to be a lot bigger, but it actually isn't. It's around 100mb smaller to my own surprise. Not sure how much that means about being the most lightweight it can be. Either way I'm not very concerned with that. I want it to work and be convenient.

If you are trying to use it and have any problems with it. You can report them here.

[JimH]

Thanks!

[Scobie]

Nice one thanks Max. Is the WebUI the key difference between this and the existing docker image?

Cheers

[max096]

From a user perspective probably. More or less. Technically its very different, it was built from scratch, because the base image ive used installs some software that's different. Like s6-overlay instead of supervisord. It uses volume mounts instead of a data container. And it does use openbox instead of nothing. Most of those choices were made by the creator of the base image, not really by me. I wasnt familiar with most of it, but rolled with it anyway. It wasnt really that hard, other than I had to write some service script to prevent jriver from being minimizeable. Not sure if what I did is the best way to do it, but I didnt have to turn the base image upside down to achieve it.

The other docker images for jriver all seem to be essentially this one https://github.com/cassfras21/docker-jrivermc with a different jriver version installed.

[max096]

Whats also cool that I used the gilab ci pipeline for building the containers. So automated scheduled builds can be enabled with like a click of a button. I dont do that (yet) for stable and latest. But I probably will at some point and fork off working tags like 25.0.50. Its not really that likely that a rebuild would break latest and stable, I dont think, but its definitely possible. But that would keep the image from being outdated, really ever. If you wanna keep using to the same image you'd just use the version tags instead.

But if you want the latest stable or latest latest version, you won't have to build it from source that way.

[max096]

Did change something in the openbox config. Now the JRriver Window should always stay in the background.

Before if you opened some option window and then clicked on the jriver window. That brought the main JRiver window in front of the options window. And then you could not do anything until you restarted the container (since you cannot interact with jriver when the option window is open and you cannot interact with the option window when the jriver window is in front of it).

[shortie]

Excellent, thank you! Good choice for the base image, too. I’m especially pleased that you provided a compose as well as a Dockerfile, rolled it all up into gitlab and have it set up for ci.

[max096]

Glad you like it. 

Another thing that I wanted to try at some point is use http://eradman.com/entrproject/ to force an auto import as soon as a file changes within your music directory. Wherever it is. You´re gonna configure that "somehow" (or do nothing and it will just not do anything). I don´t know specifics yet, since I didn´t even start doing that. But etr being a linux native utility for executing something on file changes will absolutely instantly react to anything that changes, while jriver seems to do that on a set schedule (so sometimes it may take a while) and then I usually go to the UI and hit "Run Auto Import Now". How about not needing to do that anymore?

[bob]

Glad you like it. 

Another thing that I wanted to try at some point is use http://eradman.com/entrproject/ to force an auto import as soon as a file changes within your music directory. Wherever it is. You´re gonna configure that "somehow" (or do nothing and it will just not do anything). I don´t know specifics yet, since I didn´t even start doing that. But etr being a linux native utility for executing something on file changes will absolutely instantly react to anything that changes, while jriver seems to do that on a set schedule (so sometimes it may take a while) and then I usually go to the UI and hit "Run Auto Import Now". How about not needing to do that anymore?

MC uses inotify to update automatically when files are on a local filesystem.
inotify doesn't work for cifs so the fallback is to the timed auto-checking on cifs mounted filesystems. There may be other filesystems that don't work for inotify either.
Note that the auto-import can be triggered from JRemote (iOS, not sure about android).
Also since it's a MCWS command you could make a curl string to the localhost:52199 MC library server to do the same as well.

[max096]

MC uses inotify to update automatically when files are on a local filesystem.
inotify doesn't work for cifs so the fallback is to the timed auto-checking on cifs mounted filesystems. There may be other filesystems that don't work for inotify either.
Note that the auto-import can be triggered from JRemote (iOS, not sure about android).
Also since it's a MCWS command you could make a curl string to the localhost:52199 MC library server to do the same as well.

I don't use CIFS mount (on my main jriver instance anyways), since the mdadm raid6 formatted with etx4 is local to the system running the container. But I did volume mount it into the docker container. All I can say is that it does not work instantly for me now (and never did, since I was using docker) and it most likely will be consistently the same with any filesystem and mount option you use, since at the end of the day you are always gonna have to use docker volume mounts to map your music, or you don't have your music inside the container.

As I said I didn't even really start doing that. That's something that will appear in the dev-tags, whenever I find time to do so. But if it works out perfectly, I'll probably be putting that into the stable and latest tags to as an option to use.

I wasn't really planning on using curl, because it might be needing logins (and seems unnecessarily to do an http request) and there appear to be MC core commands available for triggering autoimport from the CLI.

Another option would be to forgo auto-import entirely and use the import methods instead. But that would also mean I'd have to do the delete and all those "fixing broken links" things when files change. Just run auto import seems a h3ll of a lot simpler. Although, you'd have 2 auto import triggers running at the same time then. Witch isn't perfect either. And ditching auto import would mean, you would not even have to configure JRiver at all to import your music. You just tell it /data (for example) is where my music is in the docker run command. Mount 10 directories under /data/music1 /data/music2 and it just kinda would go ahead and do that, without auto import ever being a thing. So that sounds nice, but I probably won't do that, because delegating the work to JRiver's autoimport seems just that much easier to do without introducing potential bugs.

---

OR... you update JRiver to work well with docker volume mounts and I don't try anything... ^^

[BryanC]

Code: [Select]

MC uses inotify to update automatically when files are on a local filesystem.
inotify doesn't work for cifs so the fallback is to the timed auto-checking on cifs mounted filesystems. There may be other filesystems that don't work for inotify either.
Note that the auto-import can be triggered from JRemote (iOS, not sure about android).
Also since it's a MCWS command you could make a curl string to the localhost:52199 MC library server to do the same as well.
I don't use CIFS mount (on my main jriver instance anyways), since the mdadm raid6 formatted with etx4 is local to the system running the container. But I did volume mount it into the docker container. All I can say is that it does not work instantly for me now (and never did, since I was using docker) and it most likely will be consistently the same with any filesystem and mount option you use, since at the end of the day you are always gonna have to use docker volume mounts to map your music, or you don't have your music inside the container.

As I said I didn't even really start doing that. That's something that will appear in the dev-tags, whenever I find time to do so. But if it works out perfectly, I'll probably be putting that into the stable and latest tags to as an option to use.

I don't really wanna be using curl, because it might be needing logins (and seems unnecessarily) and there appear to be MC core commands available for triggering autoimport from the CLI.

Another option would be to forgo auto-import entirely and use the import methods instead. But that would also mean I'd have to do the delete and all those "fixing broken links" things when files change. Just run auto import seems a h3ll of a lot simpler. Although, you'd have 2 auto import triggers running at the same time then. Witch isn't perfect either. Though ditching auto import would mean, you would not even have to configure it at all. You just tell it /data (for example) is where my music is. Mount 10 directories under /data/music1 /data/music2 and it just kinda would go ahead and do that, without auto import ever being a thing.

---

OR... you update JRiver to work well with docker volume mounts and I don't try anything... ^^

Have you tried a bind mount?

[max096]

Have you tried a bind mount?

https://docs.docker.com/storage/bind-mounts/

Afaik, bind mount is volume mount --volume -v as in volume mount. That's what the flags stand for.

[BryanC]

Well then it should work as long as you have inotify-tools installed.

It looks like your base image doesn't include inotify-tools OOTB, have you installed them as part of your MC installation?

[max096]

Well then it should work as long as you have inotify-tools installed.

It looks like your base image doesn't include inotify-tools OOTB, have you installed them as part of your MC installation?

I have not explicitly installed them. Unless it does install with the repo/apk, I didn't. I'll see what happens when I install them them then.

EDIT:
I installed 'inotify-tools' in the dev images now. Gonna test that tomorrow as it's kinda late now for me and i gotta sleep at some point. I'm gonna reply tomorrow wether that worked or not. It also was a problem before with the JRiver container build by jatzoo for jriver24 for me. So I'm not sure if it's gonna solve it. But i'll test it and see. Before with that river24 mage it sometimes worked instantly, but it seemed to be a pure luck kinda thing and not consistent at all. Sometimes you sit around for a minute and wait.

[BryanC]

Source for that info: https://stackoverflow.com/a/46804953

It doesn't make sense to me that MC wouldn't just rely on the kernel inotify, but I'm not a Docker guy and Stackoverflow says you need the tools, so there you go.

[mwillems]

I wasn't really planning on using curl, because it might be needing logins (and seems unnecessarily to do an http request) and there appear to be MC core commands available for triggering autoimport from the CLI.

I don't think the CLI core commands are actually implemented on Linux, you have to go through MCWS (or at least the core commands weren't implemented the last time I was doing Linux automation scripting last year).

FWIW, inotify with JRiver works perfectly outside of docker, hopefully it can be made to work inside docker.  You may need to increase the number of inotify watches in limits.conf (or the docker equivalent), though; the default max watch count is pretty low, and needs to be increased for large libraries.

[max096]

I didnt have time yesterday to do that.
But today I should have.

Installing inotify-tools changed the container size by 0mb, so Id say it did absolutely nothing, unless its just that small.

Im not sure I have those tools installed on my host system. Maybe I need them there, since docker uses the hosts kernel. Docker may forward some events from the host to the container in that way. Im absolutely not sure about that. But something else im gonna try if that does not work now.

My library is somewhere in between 2000 and 3000 files. Is that a large library? ^^

---

It's actually that small that it does not change the image size (it wasn't installed on the image before). But it does not fix it either to install it.

https://imgur.com/a/FuC5BQk

Installing it on the host does not do anything (that would have been odd anyways). And selinux is also not the problem as ive turned it off now.

[max096]

Do I need to enable something in JRiver for the auto import to work?

I just did a clean debian9 install, with all the defaults. Installed JRiver on it, made sure inotify is installed too (your repo does not install it as a dependency) and it does not work either.

https://imgur.com/a/1AuE1H9

It does work on Windows though.
And on MacOS too (just was curious lul)

[BryanC]

Do I need to enable something in JRiver for the auto import to work?

I just did a clean debian9 install, with all the defaults. Installed JRiver on it, made sure inotify is installed too (your repo does not install it as a dependency) and it does not work either.

https://imgur.com/a/1AuE1H9

It does work on Windows though.
And on MacOS too (just was curious lul)

In the meantime, I've always found it helpful to add a "Run Auto-Import Now" button to the MC toolbar.

You could also program your own inotify-based watcher with systemd and execute the auto-import command via MCWS.

[max096]

In the meantime, I've always found it helpful to add a "Run Auto-Import Now" button to the MC toolbar.

You could also program your own inotify-based watcher with systemd and execute the auto-import command via MCWS.

Ye, I know. But you guys said it works perfectly fine on Linux. So its logical to try and get it to work without starting to do make your own.

[bob]

I don't think the CLI core commands are actually implemented on Linux, you have to go through MCWS (or at least the core commands weren't implemented the last time I was doing Linux automation scripting last year).

FWIW, inotify with JRiver works perfectly outside of docker, hopefully it can be made to work inside docker.  You may need to increase the number of inotify watches in limits.conf (or the docker equivalent), though; the default max watch count is pretty low, and needs to be increased for large libraries.

This is correct, you can't trigger things in a running MC using command line tools, you need to send a MCWS command via the listener at localhost:52199

[bob]

Auto import directories aren't configured by default in linux MC.
Once you have configured a auto-import Music directory (the default is obtained by asking Open Desktop and if that's not configured it uses ~/Music) the import will happen automatically IF you have inotify installed OR on startup and once every 120 minutes.

[max096]

Auto import directories aren't configured by default in linux MC.
Once you have configured a auto-import Music directory (the default is obtained by asking Open Desktop and if that's not configured it uses ~/Music) the import will happen automatically IF you have inotify installed OR on startup and once every 120 minutes.

As can be seen in the debian9 screenshot. I have configured ~/Music as a directory for autoimport. I also installed inotify tools (but you cant see it on the screenshot). But its not doing it. It only happens on startup, or when changing something in auto import settings or when hitting run auto import now.

That's as plain as it gets for a debian install. I just installed it yesterday in KVM. i'm not sure how that's supposed to work if it does not work there either. The music directory is local and is the default music directory in the users home directory. I just clicked on the configure auto import thing, remove everything there and added that directory (~/Music). Installed inotify-tools before that and it does not work. So i`m not sure how that's supposed to "just work fine". Do you have a Linux machine where it's working on 25.0.50? It does not work on my bear metal Fedora install either. That does not necessarily say much since Fedora isn't officially supported. That's the reason I installed a Debian VM to figure out if it works there and it didn't.

[bob]

from a terminal window in the container type
mount
and post the results here.
Thanks.

[max096]

from a terminal window in the container type
mount
and post the results here.
Thanks.

Sorry, but I don't exactly know what you want from me here.

it's not about a container anymore. It does not seem to work for me on a debian9 VM no container docker what so ever involved. Just clean install of debian9 with nothing but debian and jriver on it.

[bob]

Sorry, but I don't exactly know what you want from me here.

it's not about a container anymore. It does not seem to work for me on a debian9 VM no container docker what so ever. Just clean install with nothing but debian and jriver going on.

Then just do the mount command from the VM terminal window and post the results here.

[max096]

Then just do the mount command from the VM terminal window and post the results here.

I can tell you in like an hour or two, but I dont think youll see much going on there. Presumeably just one mount for the rootfs, maybe a swap and maybe a home mount. Whatever debian does when you next>next the installer, didnt check.

EDIT: That's the output of mount on debian9. I thought that would look more similar to lsblk.

Code: [Select]

max@debianvm:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=4078064k,nr_inodes=1019516,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=817872k,mode=755)
/dev/vda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15413)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /run/user/117 type tmpfs (rw,nosuid,nodev,relatime,size=817868k,mode=700,uid=117,gid=121)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=817868k,mode=700,uid=1000,gid=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
max@debianvm:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom 
vda    254:0    0   50G  0 disk
├─vda1 254:1    0   42G  0 part /
├─vda2 254:2    0    1K  0 part
└─vda5 254:5    0    8G  0 part [SWAP]

And this is mount from the docker container

Code: [Select]

max@centx:~ $ docker exec -it jrivermc25 /bin/bash
root@centx:/tmp# mount
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/Y63IPGLWKRCPPBTML5ZH4X5AM7:/var/lib/docker/overlay2/l/5SZD3GCYYAEV3ZCQZJMU7QN42J:/var/lib/docker/overlay2/l/ZN6QBUQMUJ6MYMJQGVNJ66CLTF:/var/lib/docker/overlay2/l/I6YNT6P5CEPM55KTFKKM3YML3Z:/var/lib/docker/overlay2/l/F6GHEC34PFPAN744DILBIFTUQK:/var/lib/docker/overlay2/l/Y77QHETEFECFYTT5GPBD52U2KF:/var/lib/docker/overlay2/l/Y6FR3TRGAQGWMKEJS4ABI436ZR:/var/lib/docker/overlay2/l/VHGK6VBUAYF7DEGBQHTFYQDDYO:/var/lib/docker/overlay2/l/FPWW6DYNC4RFNAO36CO7ZDXWOZ:/var/lib/docker/overlay2/l/BV3U2GNIHCRDA2LNPEIMWVQ7LG:/var/lib/docker/overlay2/l/HPT4JZJNT5LLGP7VVTWK5VC65M:/var/lib/docker/overlay2/l/WNRCMEXOJUGZUSEN57GQYSTEGC:/var/lib/docker/overlay2/l/Z4LG753DJDQVHOIT4BVVRAUTLL:/var/lib/docker/overlay2/l/6W2IMG3MV3N346OLSJL6YR4KGS:/var/lib/docker/overlay2/l/XY5LF527KV5SZJ66XHSWVLBEMO:/var/lib/docker/overlay2/l/67AEHOY3U54DFNOFCTXBEQCHB5:/var/lib/docker/overlay2/l/A64WXJ7K4P6X3ERVZBJYLNAF43:/var/lib/docker/overlay2/l/NER624XQ4WI4HBPE4LAOXRRGOG:/var/lib/docker/overlay2/l/Z7SG5NKMJOD7PUXV5ALJB7VVGF:/var/lib/docker/overlay2/l/XNYZ4GDWFWHS7ETIHOCU5SZ2E6:/var/lib/docker/overlay2/l/YA5IDQ7P2JLFJGPKYRBXWZ2JX4:/var/lib/docker/overlay2/l/46ROJY4LUQBJGOF4GZNB4QEQY3,upperdir=/var/lib/docker/overlay2/0e117796a0bf42013c4df02967440f68c08803e101923806eac9b80f30dd5733/diff,workdir=/var/lib/docker/overlay2/0e117796a0bf42013c4df02967440f68c08803e101923806eac9b80f30dd5733/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/centos-home on /config type xfs (rw,relatime,attr2,inode64,noquota)
/dev/md127 on /data/music type ext4 (rw,relatime,stripe=64,data=ordered)
/dev/mapper/centos-root on /etc/resolv.conf type xfs (rw,relatime,attr2,inode64,noquota)
/dev/mapper/centos-root on /etc/hostname type xfs (rw,relatime,attr2,inode64,noquota)
/dev/mapper/centos-root on /etc/hosts type xfs (rw,relatime,attr2,inode64,noquota)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
proc on /proc/bus type proc (ro,relatime)
proc on /proc/fs type proc (ro,relatime)
proc on /proc/irq type proc (ro,relatime)
proc on /proc/sys type proc (ro,relatime)
proc on /proc/sysrq-trigger type proc (ro,relatime)
tmpfs on /proc/asound type tmpfs (ro,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_stats type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/scsi type tmpfs (ro,relatime)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
root@centx:/tmp# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0   7.3T  0 disk 
`-sda1        8:1    0   7.3T  0 part 
  `-md127     9:127  0  14.6T  0 raid6 /data/music
sdb           8:16   0   7.3T  0 disk 
`-sdb1        8:17   0   7.3T  0 part 
  `-md127     9:127  0  14.6T  0 raid6 /data/music
sdc           8:32   0   7.3T  0 disk 
`-sdc1        8:33   0   7.3T  0 part 
  `-md127     9:127  0  14.6T  0 raid6 /data/music
sdd           8:48   0 465.8G  0 disk 
|-sdd1        8:49   0   200M  0 part 
|-sdd2        8:50   0     1G  0 part 
`-sdd3        8:51   0 464.6G  0 part 
sde           8:64   0   7.3T  0 disk 
`-sde1        8:65   0   7.3T  0 part 
  `-md127     9:127  0  14.6T  0 raid6 /data/music
sdf           8:80   0   2.7T  0 disk 
`-sdf1        8:81   0   2.7T  0 part 
sdg           8:96   0   7.3T  0 disk 
`-sdg1        8:97   0   7.3T  0 part 
nvme0n1     259:0    0 931.5G  0 disk 
`-nvme0n1p1 259:1    0 931.5G  0 part

I'm not exactly sure what docker is trying to accomplish there having the data/music directory be there 3 times and listing drives from the host system within the container.
The fun thing is you cannot actually use mount yourself to mount or unmount anything inside the container as that's locked down (supposedly for security/ensure isolation reasons), docker does whatever it does on it's own.

EDIT:
Oh... wait its there 4 times so. Its the 4hdds forming the raid... Im dumb. It just lists all the HDDs from my host in the container. I deffinitely have all of those. Makes sence now.

[max096]

I now updated the images so latest is on 25.0.62 and stable on 25.0.50. For what its worth they also include inotify-tools. Maybe it works for someone else...

[max096]

Did you get anywhere with the logs I supplied?  ?

---

Otherwise, do you have any plans on making a way available to access MWCS (or methods in general) when already on the PC where JRriver is running without any authentication?

I don't care if it's from the CLI, or if you figure out a way to bypass authentication when the request comes from localhost (relieably), or if you provide some kind of CLI that supplies an api key that you can authenticate to MWCS with. Any of those would work. Whatever works best for you is fine.

I just think it's very unpractical to implement any extra features into this container when you need authentication for them if the user of the container sets a password. He'll have to set the username and password twice, since I would need access to it in plain text to be able to authenticate in MWCS. Neither do I like the need to put the plain text password into the docker configuration, nor do I like the requirement to configure it twice every time it's changed.

That would also be useful for everybody automating anything in JRiver. You don't really want to put your plain text credentials into script as long as you can avoid doing so.

[bob]

Looks like there might be issues with inotify and overlay filesystems.
https://github.com/libuv/libuv/issues/1201

We added a panel option to trigger a import.

[shortie]

I’m not sure why but when I hit the About box, the dialog now pops BEHIND the main window. i can’t find a way to move the main window so i must shut down the container and restart it. Not sure if that’s a change in behavior or not.

Also, I’m curious...is the only way to update to a newer version of MC to ‘docker rmi’ and recreate the image? What do you do about the license in that case?

[bob]

I’m not sure why but when I hit the About box, the dialog now pops BEHIND the main window. i can’t find a way to move the main window so i must shut down the container and restart it. Not sure if that’s a change in behavior or not.

Also, I’m curious...is the only way to update to a newer version of MC to ‘docker rmi’ and recreate the image? What do you do about the license in that case?

The window manager is doing that, I can't tell you why.
Since the about box has focus and since we added the ability to close those boxes by hitting OK you might just try hitting enter and see if your main window regains control.

[max096]

I’m not sure why but when I hit the About box, the dialog now pops BEHIND the main window. i can’t find a way to move the main window so i must shut down the container and restart it. Not sure if that’s a change in behavior or not.

Also, I’m curious...is the only way to update to a newer version of MC to ‘docker rmi’ and recreate the image? What do you do about the license in that case?

I believe the issue you are having is already resolved. Try to pull the latest image and then restart it. Stable or latest does not matter. I had this happen too and changed the openbox config to resolve that.

License and other thing should all the persisted in your home directory /config. Hence as long as you mounted that everything (including license) should persist if you destroy and recreate the container. If you didnt mount it everything will be gone. But you (can) use docker cp to copy a foder from your container to your host.

So either docker-compose pull, or docker pull shiomax/jrivermc25:latest or pull stable. Depends on wether you use compose or not. If youre not using compose you have to specify witch image to pull exactly. With compose its whatever is in your compose and default would be latest.

[shortie]

I believe the issue you are having is already resolved. Try to pull the latest image and then restart it. Stable or latest does not matter. I had this happen too and changed the openbox config to resolve that.

just did a docker-compose pull, docker-compose down then docker-compose up -d and it's still happening. I should have it but is there anything I can check in the container to see if I've got your latest? Here's the date stamp of rc.xml in the container

# ls -l /etc/xdg/openbox/rc.xml
-rw-rw-r-- 1 root root 12071 Jun 14 19:03 /etc/xdg/openbox/rc.xml

[max096]

cat /etc/xdg/openbox/rc.xml

The config should have this inside at the very end

Code: [Select]

<applications>
  <application type="normal" title="JRiver Media Center 25">
    <decor>no</decor>
    <maximized>true</maximized>
    <layer>below</layer>
  </application>
</applications>

The part I changed was the layer below, witch it should only do for the JRiver Media Center 25 window.

When you type in docker inspect <image id or name> (can find that when you run docker ps -a) you'll also see a hash for that version, being

Code: [Select]

"Image": "sha256:331b71b3a21eb91bc81775befc7e42167eb8fcabf54e9755afcb199093aaf0e9"
for the current :latest image. But that's not fun to compare.

---

Since you already get that on start the image possition might be saved somewhere in the config directory. Can you try to start the container without mounting the config directory and see if that resolves that. You can mount it again later, I just wanna know if there is something inside that might be causing that. Because when you first create the image the Window also is not maximized, but once you maximize it it opens that way again on re-creation. So there has to be something saving image positions inside the config. Might be JRiver itself (is my guess, because I already rm -rf't basically everything except for the .jriver folder and documents).

---

Code: [Select]

<decor>no</decor>
<maximized>true</maximized>

Those two lines don't actually work by the way (if you're wondering). That's down to JRiver not using standard window decoration and as such openbox can't control it in these ways. but the behind thing worked and those two lines work for every JRiver window, except for the main Window (if you put a * instead of JRiver Media Center 25 for the title selector). The title selector is definitely the right one for that window, just some things won't work. I also tried to set it's position to x=0 and y=0 and the width and height property to the screens width and height. That does maximize it, but breaks the Window. You can no longer use it until you minimize/maximize it, so there is no point to that. I'm pretty sure it's only the Main JRiver window that is causing those problems. If we could set it to not use custom window decorations, it would work out fine most likely. However, I already asked for that once in a different context and they told me it would require a complete UI rework. So that's not happening. Hence we have to fiddle with things like this container more than we usually would have to, to force it to "behave" somehow against it's will.

---

The 1 millions't edit

OK, so <maximized>true</maximized> seems to actually work, I just built a image without this and it does not maximize. I'm pretty sure when I first tried all of this it never maximized on the first start even though that was in there.

[shortie]

cat /etc/xdg/openbox/rc.xml

Yes, that's there verbatim. There's no ps command so I can't check to make sure openbox is running...wait, I can try to start it again. Right that fails because it says it's already running. I can't seem to find any log files but I suppose none of that matters because I cant find an editor to try to modify rc.xml. Any other ideas? Are you in a place where you can check your personal installation?

[max096]

Yes, that's there verbatim. There's no ps command so I can't check to make sure openbox is running...wait, I can try to start it again. Right that fails because it says it's already running. I can't seem to find any log files but I suppose none of that matters because I cant find an editor to try to modify rc.xml. Any other ideas? Are you in a place where you can check your personal installation?

Yes, I am and it's working fine for me. I can open the about window and click the JRiver window to my hearts content and it stays on top of the jriver window.

The "docker ps" command is from outside the container. But you are right, you don't really have a whole lot inside the container, no editor, no package manager, no systemd, no nothing basically. I'm not even sure how you can restart openbox within the container without restarting the container (but you have cat). It has just what it needs to run at all, not to be a functional linux system for use. If you wanna edit things you should probably either copy the openbox.rb from my gitlab and mount it into the container. Or clone the entire thing and build the image from there.

Do you now have that line

Code: [Select]

<layer>below</layer>

in your file or not?

From your host when you run

Code: [Select]

docker exec -it <container name or id> /bin/bash
cat /etc/xdg/openbox.rb

Do you have the line in there?

I'm not sure you have, since it kinda seems like you do, but then also want an editor, witch suggests you don't?

---

Effectively, that's what I wanted you to do try, see if that line is there and make sure you have the latest image.
https://youtu.be/PyTgtFgBTJU

As you can see in that video at the end too. I can click around everywhere and the window stays on top, or rather the jriver main window stays below. But that's effectively kinda the same thing.

Also by the way you need to run the docker-compose command while you are inside the direcory where your docker-compose.yml is. Just thought that might be a problem. Since I didn't mention this anywhere and it's not like a package manager. It looks for docker-compose.yml in the directory where you are unless you specify a file in the command.

---

Other than that when you confirmed that you do in fact have the lastest image, did you try to remove the config volume from the compose file and restart the container then?

In the video I was using this compose.yml

Code: [Select]

version: '3'
services:
  jrivermc25:
    image: shiomax/jrivermc25:latest
    restart: always
    container_name: jrivermc25
    ports:
      - "5801:5800"
      - "5900:5900"
      - "52100:52100"
      - "52101:52101"
      - "52199:52199"
      - "1900:1900/udp"
    environment:
      - VNC_PASSWORD=12345
    volumes:
        - ./config:/config:rw
        - ./music:/data/music:rw

So you'd be removing this line "- ./config:/config:rw" from the config and then once again "docker-compose down && docker-compose up -d"

[shortie]

sorry, I wasn’t clear...yes, the lines you posted are at the bottom of the rc.xml file in /etc/xdg/openbox.

i was using the docker exec -it <container> /bin/bash to gather that info. I was looking for the ps command in the container so i could see what was running and i was hoping for an editor so i could fiddle with the rc.xml file and see if i could change the behavior.

I rebuilt just before I posted those comments and i saw, from Panel, that i was running the latest image (65).

I was hoping to not have to clone your whole repo but since you’re not seeing these issues it looks like it’s something in my setup. I’ll fiddle with it and post when i find something. Thanks for your help and patience.

I’ll try removing the config volume and see if that changes things.

[max096]

I was hoping to not have to clone your whole repo but since you’re not seeing these issues it looks like it’s something in my setup. I’ll fiddle with it and post when i find something. Thanks for your help and patience.

What you could also do is just download the rb file and add it to your container

Code: [Select]

volumes:
     ./rc.xml:/etc/xdg/openbox/rc.xml:rw

In that way you can effictively replace any file you want inside the container with your own.
But otherwise the only real way I know of is to build the image. There is a "buildup.sh" in the root of the project that you can use to quickly build a create a container. You can comment out the line in the dockerfile that makes the icon from the png, since it takes quite a significant time of the build process.

Hope you can fix your issue, I'm kinda in the dark here too without being able to reproduce the issue.

[shortie]

It looks like its something in my config directory. I moved my old one out of the way and created a new directory that I mount on config in the container and it's working fine. Not sure what I could've done to cause the behavior I was seeing but OK now. I'll just re-import my libraries and continue. Thanks for the help and sorry for the confusion.

(I really do know what I'm doing, here  ... I've been working with docker for well over a year in my day job and fiddling with it at home for a little longer. Man, I feel like an idiot! )

[max096]

It looks like its something in my config directory. I moved my old one out of the way and created a new directory that I mount on config in the container and it's working fine. Not sure what I could've done to cause the behavior I was seeing but OK now. I'll just re-import my libraries and continue. Thanks for the help and sorry for the confusion.

(I really do know what I'm doing, here  ... I've been working with docker for well over a year in my day job and fiddling with it at home for a little longer. Man, I feel like an idiot! )

That's good. Kinda. Except, now it's something in the config directory that really should not happen in the first place imo. If I know what file it is that persists such things I can purge it on start or/and stop of the container and then a restart would fix it whenever it happens. It should not be persisting things about Window possitions and so on that's stupid.

So, it's good that it works for you now. But bad that I have no idea what exactly was happening, yet... 

[shortie]

That's good. Kinda. Except, now it's something in the config directory that really should not happen in the first place imo. If I know what file it is that persists such things I can purge it on start or/and stop of the container and then a restart would fix it whenever it happens. It should not be persisting things about Window possitions and so on that's stupid.

So, it's good that it works for you now. But bad that I have no idea what exactly was happening, yet... 

I’ve got my old config directory...i’ll try to find the time to sort thru all the files and try to figure out which is/are the culprit(s)

[shortie]

I found nothing definitive when comparing the directories but I think I may have an idea now just from using it. I think it may have to do with either moving the window or resizing it. Those are the only two things I've done since clearing my config directory and installing from scratch.

UPDATE: It doesn't seem to have anything to do with moving the window. I haven't been able to figure out how I resized it before.

[max096]

I found nothing definitive when comparing the directories but I think I may have an idea now just from using it. I think it may have to do with either moving the window or resizing it. Those are the only two things I've done since clearing my config directory and installing from scratch.

UPDATE: It doesn't seem to have anything to do with moving the window. I haven't been able to figure out how I resized it before.

Might have happened on an older version of the container. In witch case you might no longer be able to reproduce it without having the config dir from an old container where that happened.

[shortie]

There's something in the .jriver directory that's causing this. After the last failure I moved the config directory (which includes the .jriver directory) out of the way so MC would create a new one. Of course that new instance didn't evidence the problem. I brought the container down then copied the ,jriver directory from the failing instance into the good instance, brought the container back up again, and it failed in the same way. I ran some diffs and thought it had something to do with User Settings.ini but copying the good one into the bad one didn't change the behavior (I brought the container down before the copy).

I'll keep fiddling and post if/when I zero in on something.

[max096]

Automatic music import works for me now too (instantly). Not sure since when. But it sure does, now! 

[max096]

Just found another bug. I wasn't able to input anything into the textboxes in any of the options. That has been fixed now though. Didn't notice this myself since back when I created the container it worked. But the script that I wrote to force the window to not be minimize-able broke it. Now it works again.

[max096]

If anybody had a problem with high cpu usage, because of repeated "screen -l" This now works much better. I didn't notice this running it on my NAS. But I now have set up a VM for some testing for another project with a single fairly low-end vcore (around 10% of my 4790k in that system). It was using around 90% cpu doing nothing. All of which was due to calling "screen -l" A LOT. Now this is down to 2% usage on that same system.

So, I would highly recommend to anybody who is using this container now and cares about cpu usage to update to one of the new builds.

That's about the only change that happened screen is gone. R.I.P. screen. The issue didn't really happen because of screen, but because when calling screen the command effectively is done immediately. x6-overlay then assumes the service is dead and runs the start script again for that service. Then it does that again... and again.. until the end of days. I knew that before, that's why I checked wether the screen is already running in the startscript. But I wasn't aware that this can use up quite a bit of cpu usage.

[max096]

I now have done the "version" tagging I said I was gonna do when the docker image is stable.

The tags latest and stable are rebuilt every sunday to the newest version of the base image and jriver of the stable and latest repository.

Whenever a new JRiver version is released it's also gonna create a tag with "25.0.50-stable-1" for example.
The first part being the JRiver version. The second the repository and the third one is the image version (meaning whenever I change something that changes the resulting image the number will go up). The image from 0 to 1 didn't really change. All that changed was I included a VERSION file within the image that contains the image version. Before there was no version. So the two images that existed before are now "25.0.50-stable-0" and "25.0.80-latest-0".

Old versions won't be built. But if in the future a new base image or new jriver version ends up causing problems, you can easiely revert to an older version, by changing the tag.

[max096]

I found nothing definitive when comparing the directories but I think I may have an idea now just from using it. I think it may have to do with either moving the window or resizing it. Those are the only two things I've done since clearing my config directory and installing from scratch.

UPDATE: It doesn't seem to have anything to do with moving the window. I haven't been able to figure out how I resized it before.

Do you still have that directory that bailed? If so Im curious if the current container would fix that. Any of them. I think with the current container even if a window where to pop up behind something it should be pulled in front right after the window changed.

Otherwise, could you send me said directory confidentially? Just send me a private message then, not a good idea to post folders that potentially contain license information on a public forum.