INTERACT FORUM
More => Old Versions => JRiver Media Center 25 for Linux => Topic started by: max096 on June 10, 2019, 06:21:55 pm
-
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.
-
Thanks!
-
Nice one thanks Max. Is the WebUI the key difference between this and the existing docker image?
Cheers
-
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.
-
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.
-
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).
-
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.
-
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?
-
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.
-
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... ^^
-
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?
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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)
-
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.
-
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.
-
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
-
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.
-
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.
-
from a terminal window in the container type
mount
and post the results here.
Thanks.
-
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.
-
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.
-
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.
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
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.
-
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...
-
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.
-
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.
-
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’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.
-
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.
-
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
-
cat /etc/xdg/openbox/rc.xml
The config should have this inside at the very end
<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
"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).
---
<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.
-
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?
-
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
<layer>below</layer>
in your file or not?
From your host when you run
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
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"
-
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.
-
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
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.
-
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 ;D ... 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! ::) )
-
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 ;D ... 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... :-\
-
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)
-
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.
-
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.
-
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.
-
Automatic music import works for me now too (instantly). Not sure since when. But it sure does, now! :)
-
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.
-
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.
-
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.
-
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.
-
I'm not sure I'm totally following this but in general you don't want to alter anything in the home directory at all between container runs.
Also, if there are window size/position issues, we just added an option to the Tree and View settings to reset all of window size/position settings to default upon the next run.
-
I'm not sure I'm totally following this but in general you don't want to alter anything in the home directory at all between container runs.
Also, if there are window size/position issues, we just added an option to the Tree and View settings to reset all of window size/position settings to default upon the next run.
Yes, but shortie had a home directory that somehow made problems and I wanted to know if this is still the case (appearently he fixed it by making a new one). If thats still the case having the folder would make potential fixes testable. Although, seems like no one else really had that problem yet. Its quite possible its already not a problem (since 15th last months more precisely), But since I never figured out how to reproduce it, I dont know.
Thanks for the extra setting, could be useful.
However, since shortie had a problem of the about window popping up behind jriver. Depending on how it where to break you may not be able to get to the settings.
Can you add that option as a startup option "mediacenter25 /resetgui" or something like that? Then I could be adding an environment variable (or similarly) for that to start it with that option, that you can enable to recover from broken ui states.
-
No matter what I do, I can't seem to fix network problems when trying to run this docker image on OpenMediaVault 4.
I need to set the version to 2 in the .yml file, otherwise docker compose won't work, and when it does works, all ports are listening on 0.0.0.0
Has anyone been able to get this to run on any version of OpenMediaVault?
Thanks
-
No matter what I do, I can't seem to fix network problems when trying to run this docker image on OpenMediaVault 4.
I need to set the version to 2 in the .yml file, otherwise docker compose won't work, and when it does works, all ports are listening on 0.0.0.0
Has anyone been able to get this to run on any version of OpenMediaVault?
Thanks
What does docker inspect have to say about the network configuration of the container you made with v2 and v3?
Either way if v2 works fine. It is perfectly fine to run that since the version in the compose file refers to the version of the configuration file standard. It has no affect on what docker, or docker-compose version you are using. There are newer docker-compose.yml versions, but those are more targeted towards docker-swarm.
Have you tried host networking? That does work? Bridge networking is not really working on my centos ovirt NAS either, because of the firewall rules and networks ovirt setup. But host networking works and bridge networking works in VMs ovirt can host. So it may be the same thing for your openmediavault.
(EDIT: Got this part wrong at first. Now its right. The part where it sais "HostIp" made me check that again. Since that would not really make much sence otherwise, for what I initially believed it to be. Either way, I never needed to specify an IP there.)
When you run docker inspect this is kinda what´s expected when using bridge networking. I mapped the two VNC port(s) to different ports on the host. The 0.0.0.0 part is the host. You (or I) didn´t specify any IP, the 0.0.0.0 means as far as docker is concerned any host IP is valid.
You can specify an IP if you need one. Such as 192.168.1.2:5800:5800 witch would mean it´s only reachable at 192.168.1.2. Meaning if you put an IP there and run a container locally 127.0.0.1:5800 will not work. Accessing 192.168.1.2:5800 would work. With 0.0.0.0 both work. If you have multiple networks, you can restrict what networks have access to it in that way.
"NetworkSettings": {
"Bridge": "",
"SandboxID": "b9018903c4afaf3f46ce32a6881a321a4789b51620074cbb5627a1c142612c7b",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"1900/udp": [
{
"HostIp": "0.0.0.0",
"HostPort": "1900"
}
],
"52100/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "52100"
}
],
"52101/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "52101"
}
],
"52199/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "52199"
}
],
"5800/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "5810"
}
],
"5900/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "5911"
}
]
}
-
Yes, but shortie had a home directory that somehow made problems and I wanted to know if this is still the case (appearently he fixed it by making a new one). If thats still the case having the folder would make potential fixes testable. Although, seems like no one else really had that problem yet. Its quite possible its already not a problem (since 15th last months more precisely), But since I never figured out how to reproduce it, I dont know.
Thanks for the extra setting, could be useful.
However, since shortie had a problem of the about window popping up behind jriver. Depending on how it where to break you may not be able to get to the settings.
Can you add that option as a startup option "mediacenter25 /resetgui" or something like that? Then I could be adding an environment variable (or similarly) for that to start it with that option, that you can enable to recover from broken ui states.
MC child windows shouldn't popup behind the main MC window. We never specify underneath stacking and we don't alter the stacking order. You can get a window to go behind by clicking on the main window while the popup is showing IF there is a window manager since that's out of the control of MC. We've done some preliminary work to restack in that case but it's not as simple as it seems since many windows in MC are a collection of windows.
When there is a window manager ALT-Tab generally cycles through the windows. When we had a QNAP version, their window manager forced every open window to fullscreen so that it was impossible to restack the windows by accident.
-
MC child windows shouldn't popup behind the main MC window. We never specify underneath stacking and we don't alter the stacking order. You can get a window to go behind by clicking on the main window while the popup is showing IF there is a window manager since that's out of the control of MC. We've done some preliminary work to restack in that case but it's not as simple as it seems since many windows in MC are a collection of windows.
When there is a window manager ALT-Tab generally cycles through the windows. When we had a QNAP version, their window manager forced every open window to fullscreen so that it was impossible to restack the windows by accident.
shortie ended up with a container where the about window popped up behind. Witch should not happen (although Im not saying its necessarily your fault). Even in that version it worked for me. He replaced the home folder and it worked again.
Since it only ever runs one application. The way I did make this work is to write a service script that reads out all the xorg changes. Whenever the window changes it makes the last windows in existence active and thus it will be focused and on top. That didnt really quite fully work back when shortie had this happen though.
If you see any potential problem with that you can tell me. But I believe since there is only one application you really should never get into a situation where the last window you opened isnt the one you want/need to interact with. Clicking JRiver should result in jriver being active for a split second then the other one being set active by the script and it comes back.
There is an option to start windows in fullscreen in openbox too. Works for everything, but the main window (you can still make them smaller though). Maybe its also able to make them stay fullscreen. But I didnt really like the looks of it.
The current script works very well now, though. Or at least nobody has told me to have any problems with it since that one time. It still would be nice to have a plan B should it fail. Right now plan B is to make a library backup, tear down everything. And then restore the library backup. If you could do "docker exec my-jriver-container resetgui" that would be ideal I think. Now I´m not sure if it fixes it. But chances are good that it would. ^^
-
shortie ended up with a container where the about window popped up behind. Witch should not happen (although Im not saying its necessarily your fault). Even in that version it worked for me. He replaced the home folder and it worked again.
Since it only ever runs one application. The way I did make this work is to write a service script that reads out all the xorg changes. Whenever the window changes it makes the last windows in existence active and thus it will be focused and on top. That didnt really quite fully work back when shortie had this happen though.
If you see any potential problem with that you can tell me. But I believe since there is only one application you really should never get into a situation where the last window you opened isnt the one you want/need to interact with. Clicking JRiver should result in jriver being active for a split second then the other one being set active by the script and it comes back.
There is an option to start windows in fullscreen in openbox too. Works for everything, but the main window (you can still make them smaller though). Maybe its also able to make them stay fullscreen. But I didnt really like the looks of it.
The current script works very well now, though. Or at least nobody has told me to have any problems with it since that one time. It still would be nice to have a plan B should it fail. Right now plan B is to make a library backup, tear down everything. And then restore the library backup. If you could do "docker exec my-jriver-container resetgui" that would be ideal I think. Now I´m not sure if it fixes it. But chances are good that it would. ^^
Glad to hear you have it working well.
The issues I had with restacking the windows concerned a fight with other apps IIRC so I think that won't apply to you. The other thing to watch for is the windows within the window thing. Suggestion tool tips and the like. You can see with xprop that all of MC's windows have class and class names that make sense if that helps.
-
What does docker inspect have to say about the network configuration of the container you made with v2 and v3?
Either way if v2 works fine. It is perfectly fine to run that since the version in the compose file refers to the version of the configuration file standard. It has no affect on what docker, or docker-compose version you are using. There are newer docker-compose.yml versions, but those are more targeted towards docker-swarm.
Have you tried host networking? That does work? Bridge networking is not really working on my centos ovirt NAS either, because of the firewall rules and networks ovirt setup. But host networking works and bridge networking works in VMs ovirt can host. So it may be the same thing for your openmediavault.
.
.
.
Thanks a lot for the comments...
I decided to go for a "near bare-bone" setup... i.e. I removed OpenMediaVault, reinstalled Debian minimal with only SSH server, then installed ZFS, samba, docker and docker-compose
That was it... I created docker-compose.yml for host, pulled the jrivermc25 image and that was all...
I am sincerely overjoyed... no more X11, no more desktop... all was done within 45 minutes and I have a running DLNA server...
Many thanks to all those who keep JRiver alive and on the bleeding edge...
-
Thanks a lot for the comments...
I decided to go for a "near bare-bone" setup... i.e. I removed OpenMediaVault, reinstalled Debian minimal with only SSH server, then installed ZFS, samba, docker and docker-compose
That was it... I created docker-compose.yml for host, pulled the jrivermc25 image and that was all...
I am sincerely overjoyed... no more X11, no more desktop... all was done within 45 minutes and I have a running DLNA server...
Many thanks to all those who keep JRiver alive and on the bleeding edge...
A bit drastic actions..., but great that it works now! :)
-
I also built a jrivermc24 image now. Not sure if anybody asked for that... ?
I didn't ask for it either. But I was trying to make the entire build process a bit more modular (not quite there yet. 24 worked right off the bat without a single change required to the image. None of this changed the resulting container other than what JRiver version was installed and what docker repo it was pushed to.
23 didn't work, not gonna try to get that to work. Would not have tried for 24 either tbh. But since it just worked with no effort, there it is.
https://hub.docker.com/r/shiomax/jrivermc24
-
A bit drastic actions..., but great that it works now! :)
Yes, quite drastic, and I fully agree... I'm at the point where after 10+ years constantly installing / uninstalling / reinstalling, it has become kind of effortless to throw anything that doesn't work as expected out the window... :)
In the 10+ years, only JRiver (for audio only) survived the constant cleanup / replace process...
The only thing left (for me) now is to have a docker image that will allow JRiver to be set as a DLNA renderer only.
The docker image only needs to be able to use the audio card. I will be all set with JRiver forever if this would be possible.
-
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.
Well, I was just gonna try with your newest image and find that the trial expired on that directory. I guess I could license it. Thoughts?
-
Well, I was just gonna try with your newest image and find that the trial expired on that directory. I guess I could license it. Thoughts?
Have you maybe put the directory on another PC? I'm not sure if the license does stay active then. Never tried that. But otherwise it should stay active when up or downgrading the container. I've done that multiple times on the two installs of that container I have now (that are activated).
Just tried that. The license expires when you put the folder on another PC you'll have to re-enter your license.
Now it does not stay activated on that install where I got the folder from anymore either. I'm not sure yet. Maybe it solves itself. It does not even work on the older container versions where it most definitely worked before. Maybe it solves itself. Otherwise I'll have to look into it.
I also did just rebuild a new container witch would contain all the newest debian updates and all the packages (besides jriver) that's not it either.
And it does not seem to work on jatzoo's image either.
Both (seem) to activate until you shut down the container, then you are back to the trial license.
This is new, I'm not sure what's going on quite yet.
But more importantly. Did it updating that fix the gui? xD
-
Did it updating that fix the gui? xD
i haven’t been able to check that yet. Guess I’ll have to install a license but may not be able to get to it until the weekend. I’ll report back when I have a chance to try it.
-
I found out why the activation is not persisting. This isn't because the container is recreated, but because when you have a container with the default bridge networking and you recreate the container it will also create a new network. When you create a new network your license will be gone.
Since on my main install I'm using host networking the license persisted when upgrading. (With host networking you use.. well your hosts network, so you never end up creating and removing virtual docker networks).
I'll be updating the readme with those new findings. On my main install I actually use host networking. Hence it always worked. And I didn't feel like messing with it, I usually mess with other installs that are usually not around for long enough to bother activating them.
The only downside of host networking is that you cannot remap ports. And it also is not automatically accessible from the outside (as it is usually the case with bridge networking). You will end up having to configure either firewalld, ufw or just straight iptables. Depending on your distro or preference.
There should be workarounds for this with bridge networking too. At this current time I don't know of any (gotta try that too). R.I.P. my restore keys (not yet, but I've already gone threw 10 or so). But I'm sure there are ways to re-use a network (but not sure how convenient that is to administer without extra tooling). And there may be ways to specify the network in the command and in the compose file in a way that it will recreate a similar enough network for jriver to not throw away your license on re-creation (witch would include every single up and downgrade).
---
I also added a little bit of a firewall configuration section into the readme for ufw and firewalld. Depending on what you are using. Since that would be needed when using host networking. Unless you just don't run any firewall at all.
Funny how <?xml version="1.0" encoding="utf-8"?> breaks markdown on dockerhub, without escaping it and all the rest that looks like html. -.-
-
Hmmm...i already have a service running on port 5900 and can’t change it easily so i guess, given everything, MC won’t be in production for me for a while. Wait, what about changing the container’s VNC port or making it a parameter? The other ports are peculiar to MC so they shouldn’t collide with anything else, right?
I still think, though, that JRiver should distribute an official container...but not at the expense of continued Linux development :)
-
Hmmm...i already have a service running on port 5900 and can’t change it easily so i guess, given everything, MC won’t be in production for me for a while. Wait, what about changing the container’s VNC port or making it a parameter? The other ports are peculiar to MC so they shouldn’t collide with anything else, right?
I still think, though, that JRiver should distribute an official container...but not at the expense of continued Linux development :)
Turns out all that needs to be changed for bridge networking is specify a mac-address in the compose file or docker run command.
version: '3'
services:
jrivermc25:
image: shiomax/jrivermc25
restart: always
container_name: jrivermc25
mac_address: ed:e8:60:2d:65:c1
ports:
- "5800:5800"
- "5900:5900"
- "52100:52100"
- "52101:52101"
- "52199:52199"
- "1900:1900/udp"
environment:
- VNC_PASSWORD=12345
volumes:
- /path/to/config:/config:rw
- /path/to/music:/data/music:rw
docker run -d \
--name=jrivermc25 \
--net=bridge \
--restart=always \
--mac-address=ed:e8:60:2d:65:c1 \
-p 5800:5800 \
-p 5900:5900 \
-p 52199:52199 \
-p 52101:52101 \
-p 52100:52100 \
-p 1900:1900/udp \
-v config:/config:rw \
-v /path/to/music:/data/music:rw \
-e VNC_PASSWORD=12345 \
shiomax/jrivermc25
As long as your mac address does not change your license does not expire and require re-activation. But keep in mind bad things might happen if you have two machines on the same network with the same mac addresses. So if you are having more than one container. Use different mac addresses. You can find plenty of mac address generators online.
Thanks for the help @bob! ;D I would have tried to keep the entire virtual network alive. This makes it much easier.
-
Updated the image a bit
Version 2 Changelog
- xpropspy now uses sh instead of bash (microoptimization sh is faster, but can do less)
- ascii art on startup and environment variable ENABLE_SIGNATURE (1 by default)
- specifying debian-9-v3.5.2 instead of latest, witch is currently equivalent (to avoid breaking the image on automated builds)
- removed layer below for main jriver window from rc.xml as no longer needed (also seems to have fixed some ui gliches in the integrated webgui. The one inside jriver, for cloudplay and so forth.)
- added option MAXIMIZE_POPUPS to maximize every window that has the name "JRiver Popup Class" (0 by default)