Print

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

[Alex_W]

Hi all,

I'm looking into a media-server that can, in addition to the normal mp3/flac/wav/ape etc etc streaming, send DSF files to a capable renderer, or DoP to an incapable one  over UPnP/DLNA

Test-driving an MC shiomax's docker image; have an issue I'm unable to solve, and search doesn't yield anything helpful...

Host is the OpenMediaVault 5 (Debian 10), sitting on a fairly generic PC (old Dell server) hardware; Docker plugin + Portainer with their respective folders mounted externally; "host" network;
MC (25, 27, 28 versions tried) container created successfully, media library imported successfully, MC's DLNA server is visible to the devices on my LAN
Gizmo installed on a fairly generic Android tablet, can see and connect to the server, shows the library.

Now, the issue: attempting to play with Gizmo anything requiring transcoding fails miserably; the log showing:

sh: 1: /config/.jriver/Media Center 25/Plugins/linux_mp3_encoder64/lame: Permission denied

I tried playing with permissions, as mentioned multiple times on this forum (and elsewhere WRT Docker etc) -- eventually giving JRiver UID:GID of 0:0 -- nothing helped, still no playback.

VLC on the same tablet (via DLNA) _does_ play files as long as it can  transcode the files itself. Just for giggles, I installed JRMC27 on my desktop PC running Kubuntu -- and it works as expected, playing dsf files as well as the rest of them (after a workaround WRT the media library needing to have a mountpoint on the system).

Please tell me what I am missing.

Cheers,

Alex

[max096]

Can you confirm that the file it's trying to access exists? The "linux_mp3_encoder64".

Purely as a test try to "chmod -R 777 config". The config directory being the one on your host that you mount into the container.

If that solves it I would remove the config directory again and figure out proper user/group IDs from the get go.

To me it seems you played around with permissions a little too much. Because no matter what user you have configured if the docker container created the config directory. It should have access to it. Until you change user IDs after the fact it might no longer have access to it without manually changing permissions on the folder. Given that you probably don't have anything worth keeping in there best to just get rid of it and have it recreate the folder.

Not sure if user id 0 (root) works properly. Probably does not. Either way not good to do that.

[Alex_W]

thank you for responding so quickly, @max096

the file does exist, is visible via absolute path (ssh to the host machine, /srv/dev-disk-by-label...etc etc) and from inside the container (web console from Portainer), is listed as "active".

chmod'ing the directory did not solve the problem; attempting to play a file requiring transcoding results in no playback (Gizmo states "preparing", gives a series of "error communicating with server" messages); same entry in the logs.

also, I now can't seem to find that one file that Gizmo was able to start playing... so no playback at all.

thoughts?

[max096]

thank you for responding so quickly, @max096

the file does exist, is visible via absolute path (ssh to the host machine, /srv/dev-disk-by-label...etc etc) and from inside the container (web console from Portainer), is listed as "active".

chmod'ing the directory did not solve the problem; attempting to play a file requiring transcoding results in no playback (Gizmo states "preparing", gives a series of "error communicating with server" messages); same entry in the logs.

also, I now can't seem to find that one file that Gizmo was able to start playing... so no playback at all.

thoughts?

I'll try at with gizmo when I'm home. Pretty sure the current versions do work with jremote would be surprised if they don't for gizmo.

What types of files are you playing?

EDIT: Gizmo certainly seems to work for me though im using the latest MC28 container. Which one exactly are you using right now? I can try to create a fresh one with that exact image and try it. If that works there should be something wrong on your end and not with the image.

You can try to stop the container delete the config directory and have it re-create it

[Alex_W]

filetypes = mp3, ape, flac, dsf... the usual fare.

recreated the container with MC27 image; same thing happens (same entry in the logs, no playback) -- but poking more at it makes me strongly suspect it is a Permissions issue on the OpenMediaVault side of things... I'll keep testing, might need to start from the ground up (as in, re-install and re-set the docker...)

cheers,

A