More > JRiver Media Center 29 for Linux
Docker Images for MC29
max096:
--- Quote from: bob on April 29, 2022, 08:09:42 pm ---If you are running a current build, those will open internally.
Some things like last.fm still look for an external browser.
--- End quote ---
So, last.fm login will use the internal browser at some point too?
xdg-utils was already installed after installing firefox running this command it opens google in firefox
--- Code: ---env HOME=/config s6-setuidgid $USER_ID:$GROUP_ID xdg-open https://www.google.at
--- End code ---
MC in the container is running with that user/group and home set. So it should not need all that other stuff.
Still does not work though. MC logs this when pressing the button
--- Code: ---55403550: 139639333480384: Reader: CLinuxINetReader::OpenRange: Start
55403550: 139639333480384: Reader: CLinuxINetReader::OpenRange: Opening URL, Position 0
55403550: 139639333480384: Reader: CLinuxINetReader::Close: Start
55403550: 139639333480384: Reader: CLinuxINetReader::Close: This 55996efe2f60, CleanClose 0
55403550: 139639333480384: Reader: CLinuxINetReader::Close: Finish (0 ms)
55403725: 139639333480384: Reader: CLinuxINetReader::OpenRange: Elapsed MS 168.3381, initial number of headers = 8, number of loops = 0
55403726: 139639333480384: Reader: CLinuxINetReader::OpenRange: Open Succeeded. Elapsed MS 169.3668, number of headers = 8, number of loops = 0
55403726: 139639333480384: Reader: CLinuxINetReader::OpenRange: Content-Length = 114, Content-Range = , Content-type = text/xml; charset=UTF-8, Content-encoding =
55403726: 139639333480384: Reader: CLinuxINetReader::OpenRange: Finish (175 ms)
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403726: 139639333480384: Reader: CLinuxINetReader::GetLength: Start
55403726: 139639333480384: Reader: CLinuxINetReader::GetLength: Current Length 114
55403726: 139639333480384: Reader: CLinuxINetReader::GetLength: Finish (0 ms)
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403726: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403727: 139639333480384: Reader: CLinuxINetReader::Cancel: Start
55403727: 139639333480384: Reader: CLinuxINetReader::Cancel: Finish (0 ms)
55403727: 139639333480384: Reader: CLinuxINetReader::Close: Start
55403727: 139639333480384: Reader: CLinuxINetReader::Close: This 55996efe2f60, CleanClose 5
55403727: 139639333480384: Reader: CLinuxINetReader::Close: Finish (0 ms)
55403730: 139639333480384: Reader: CLinuxINetReader::OpenRange: Start
55403730: 139639333480384: Reader: CLinuxINetReader::OpenRange: Opening URL, Position 0
55403730: 139639333480384: Reader: CLinuxINetReader::Close: Start
55403730: 139639333480384: Reader: CLinuxINetReader::Close: This 55996f025870, CleanClose 0
55403730: 139639333480384: Reader: CLinuxINetReader::Close: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::OpenRange: Elapsed MS 170.3132, initial number of headers = 8, number of loops = 0
55403901: 139639333480384: Reader: CLinuxINetReader::OpenRange: Open Succeeded. Elapsed MS 170.3514, number of headers = 8, number of loops = 0
55403901: 139639333480384: Reader: CLinuxINetReader::OpenRange: Content-Length = 151, Content-Range = , Content-type = text/xml; charset=UTF-8, Content-encoding =
55403901: 139639333480384: Reader: CLinuxINetReader::OpenRange: Finish (171 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::GetLength: Start
55403901: 139639333480384: Reader: CLinuxINetReader::GetLength: Current Length 151
55403901: 139639333480384: Reader: CLinuxINetReader::GetLength: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Start
55403901: 139639333480384: Reader: CLinuxINetReader::GetInfo: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::Cancel: Start
55403901: 139639333480384: Reader: CLinuxINetReader::Cancel: Finish (0 ms)
55403901: 139639333480384: Reader: CLinuxINetReader::Close: Start
55403901: 139639333480384: Reader: CLinuxINetReader::Close: This 55996f025870, CleanClose 5
55403901: 139639333480384: Reader: CLinuxINetReader::Close: Finish (0 ms)
--- End code ---
bob:
MC doesn't use the internet reader for external browser access.
I don't know if the internal browser will work with this, I'll check.
In the meantime there still must be an issue with your setup, MC just opens the URL using xdg-open.
cncb:
Can this be swapped in to the MC 28 container or does a new one have to be created?
max096:
--- Quote from: cncb on May 01, 2022, 07:35:28 am ---Can this be swapped in to the MC 28 container or does a new one have to be created?
--- End quote ---
Not really sure why it does not work. Turning on privileged mode also does not make it work (I know chrome/chromium does use features for sandboxing by default that are not available to containers unless you run it in priviledged mode, or disable sandboxing). But firefox started without any additional flags, just not threw mc. Same thing with chromium (once privileged mode was enabled). While I donīt know how to make it work youīll be out of luck either way.
Currently working on a new container image too. Though, not for this reason. I want to get away from the current baseimage to just using debian to allow for more customization (as in having the ability to put jriver specific features into the web gui) and also better arm support. Will be some time until that is ready. No timeline whatsoever. Im not working for JRiver, so it gets worked on whenever I have time and feel like it. Hence developement is somewhat slow.
Images arenīt really ready, yet. But if youīre curious all the work is in those three repositories
- https://gitlab.com/shiomax/jrivermc-docker-next - The actual image
- https://gitlab.com/shiomax/jrivermc-docker-gui - A Vue JS Web GUI
- https://gitlab.com/shiomax/jrivermc-docker-api - C# Backend for Authentication and to be able to run code in the container savely instead of just being able to remote control MC
It does build, but there may be bugs here and there and many things are not done. Still need to work on
- Actually building the images automatically on amd64, armhf and arm64, like now but likely gonna need either 3 systems doing it or 3 vms and emulate arm, first wanted to use docker buildx, but it only builds images, it wonīt run them (you cant even save the images locally that donīt match your processor architecture). I do not think buildx is very helpful here after having tried it. Just blindly pushing images to a repo and hope for the best isnīt very useful.
- Some automated testing, probably even more important now as I can no longer rely on the baseimage to work.
- Finish up the gui
- Figure out how to change resolution at runtime. The image is no longer using x11vnc, but tigervnc instead. I found it to be more responsive and supposedly it allows for dynamic resolution updates. But I donīt know how to do that just yet. The plan is to ditch the environment variables for resolution and make it configureable in the webgui at runtime.
- Probably, need to work on User management some more (creating the user jriver will run as, adding groups, etc.)
- As first jriver integration im gonna do just the activation thing with .mjr files. Since, itīs a bit complicated right now to get that done. Wonīt plan anything else for now.
- A "stateless mode" would be cool imo. Probably, not very helpful for most people. But the plan is to on startup copy the .jriver folder into /tmp and use that, if stateless mode is enabled. So you can set up a test environment that is effectively immutable (just make your media folders read only). Would be useful for developing stuff like pymcws or anything else really that tries to integrate with jriver. Itīs not that hard to do and I think it would be nice to have, even though, as I said, most people wonīt care about it.
- Refresh Tokens that I can store in local storage, currently it stores username and password in process only, so when you refresh the page or navigate to another url in the address bar you are logged out and get redirected to login. And it also sends username, password again whenever your current token expired and you want to do something that needs authentication, so itīs not great either way.
Note that authentication is now handled by the C# api. I wrote a plugin for websockify to accept the tokens it generates. However, there is no form of authentication for direct VNC connections, but only for the webui and websockify. So, by default it should reject direct VNC connections that do not come from localhost. Something that I also still did not bother testing because well.. look at the list above. Right now it still may accept them, not sure. Either way, it is extremely likely that you wonīt be able to use direct VNC connections with the new images anymore.
Most likely, when this is somewhat reasonably ready, ill keep the old image(s) in shiomax/jrivermcxx and create another one shiomax/jrivermc-next-xx. Kind of beta release thing. At some point the plan ofc is to replace it. But it will be sometime until then.
HaWi:
--- Quote from: max096 on May 23, 2022, 03:07:04 pm ---Not really sure why it does not work. Turning on privileged mode also does not make it work (I know chrome/chromium does use features for sandboxing by default that are not available to containers unless you run it in priviledged mode, or disable sandboxing). But firefox started without any additional flags, just not threw mc. Same thing with chromium (once privileged mode was enabled). While I donīt know how to make it work youīll be out of luck either way.
Currently working on a new container image too. Though, not for this reason. I want to get away from the current baseimage to just using debian to allow for more customization (as in having the ability to put jriver specific features into the web gui) and also better arm support. Will be some time until that is ready. No timeline whatsoever. Im not working for JRiver, so it gets worked on whenever I have time and feel like it. Hence developement is somewhat slow.
Images arenīt really ready, yet. But if youīre curious all the work is in those three repositories
- https://gitlab.com/shiomax/jrivermc-docker-next - The actual image
- https://gitlab.com/shiomax/jrivermc-docker-gui - A Vue JS Web GUI
- https://gitlab.com/shiomax/jrivermc-docker-api - C# Backend for Authentication and to be able to run code in the container savely instead of just being able to remote control MC
It does build, but there may be bugs here and there and many things are not done. Still need to work on
- Actually building the images automatically on amd64, armhf and arm64, like now but likely gonna need either 3 systems doing it or 3 vms and emulate arm, first wanted to use docker buildx, but it only builds images, it wonīt run them (you cant even save the images locally that donīt match your processor architecture). I do not think buildx is very helpful here after having tried it. Just blindly pushing images to a repo and hope for the best isnīt very useful.
- Some automated testing, probably even more important now as I can no longer rely on the baseimage to work.
- Finish up the gui
- Figure out how to change resolution at runtime. The image is no longer using x11vnc, but tigervnc instead. I found it to be more responsive and supposedly it allows for dynamic resolution updates. But I donīt know how to do that just yet. The plan is to ditch the environment variables for resolution and make it configureable in the webgui at runtime.
- Probably, need to work on User management some more (creating the user jriver will run as, adding groups, etc.)
- As first jriver integration im gonna do just the activation thing with .mjr files. Since, itīs a bit complicated right now to get that done. Wonīt plan anything else for now.
- A "stateless mode" would be cool imo. Probably, not very helpful for most people. But the plan is to on startup copy the .jriver folder into /tmp and use that, if stateless mode is enabled. So you can set up a test environment that is effectively immutable (just make your media folders read only). Would be useful for developing stuff like pymcws or anything else really that tries to integrate with jriver. Itīs not that hard to do and I think it would be nice to have, even though, as I said, most people wonīt care about it.
- Refresh Tokens that I can store in local storage, currently it stores username and password in process only, so when you refresh the page or navigate to another url in the address bar you are logged out and get redirected to login. And it also sends username, password again whenever your current token expired and you want to do something that needs authentication, so itīs not great either way.
Note that authentication is now handled by the C# api. I wrote a plugin for websockify to accept the tokens it generates. However, there is no form of authentication for direct VNC connections, but only for the webui and websockify. So, by default it should reject direct VNC connections that do not come from localhost. Something that I also still did not bother testing because well.. look at the list above. Right now it still may accept them, not sure. Either way, it is extremely likely that you wonīt be able to use direct VNC connections with the new images anymore.
Most likely, when this is somewhat reasonably ready, ill keep the old image(s) in shiomax/jrivermcxx and create another one shiomax/jrivermc-next-xx. Kind of beta release thing. At some point the plan ofc is to replace it. But it will be sometime until then.
--- End quote ---
Thank you so much, Max, for continuing to improve our docker MC. I'm surely not the only one who really appreciates this. I wish I had coding skills to help but sadly, I don't :(. Buy you a drink anytime, though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version