INTERACT FORUM
More => Old Versions => JRiver Media Center 23 for Linux => Topic started by: Hendrik on October 28, 2016, 05:19:04 pm
-
Hey,
22.0.37 for Linux introduces a first draft of a Theater View port to OpenGL. Its still a work in progress, but it works well enough to actually use, so we figured why not let you test it as well!
The long-term plan is to replace even the Windows Theater View with this OpenGL version, so we have one unified across all platforms.
Requirements:
- OpenGL 3.0+ with direct rendering
- GLX 1.4
You can check these values with "glxinfo", look for "server glx version" and "OpenGL core profile version".
Any modern GPU should fullfill the OpenGL requirement, some integrated Intel GPUs may not - specifically Intel only seems to support OpenGL 3.2 starting with HD 4000, but feel free to test your own hardware with glxinfo, maybe drivers have improved!
In theory ARM might also work if it fullfills the above requirements, however in reality ARM devices often don't offer a "full" OpenGL driver, but instead have OpenGL ES, which is a subset of OpenGL and will currently not work.
Once we're further on with the development, we might try to get it working on OpenGL ES as well, so Theater View on ARM devices might happen at a later point - but this will be a while.
Current Issues/Missing Features:
- Video Backgrounds are not implemented (ie. a skin using a video file as an animated background)
- Playing Now Visualization is not (fully) implemented (only file images work, not animated visualizations)
- Reflection effects are not implemented
- Playing Now can lose focus when "Stop" is issued when its open
Please let us know about any other issues or your thoughts so far, thanks!
-
I changed the topic title from Feedback to NEW. This is a big deal. Thanks, Hendrik. Well done.
-
This is amazing news. I installed on two systems with pretty different results. Good news and bad news:
1) The Good news: On an Arch 64-bit system with intel graphics theater view works pretty well. The views are correctly inherited from the server, navigation works as expected (a little laggy, but that could be the igpu as much as anything). The remote even works! The only big issue is that stopping a track from the playing now view seems to repeatably freeze the interface (tried four times, happened every time). I can switch back to standard view with Ctrl-1, but the theater view interface appears completely non-responsive after the stop press.
2) The Bad news: an otherwise similar Arch 64-bit system with NVidia graphics (proprietary driver) immediately begins strobing as soon as theater view is entered. White flashes every second or so that seem to reset the input (i.e. the cursor returns to home). You can navigate out if you move very quickly, but it tends to hang or crash after thirty seconds or so. This machine (and my other NVidia machines) also have similar pre-existing problems with the OSD implementation, it creates similar flashes that prevent interaction, but there's alternative UI i display view so I've been ignoring it (or turning it off). Obviously I didn't get much testing in on this machine.
I can provide package/driver versions if that would be helpful. Both machines are running Gnome on X11 (Gnome recently switched to wayland by default, but I've disabled it). I'm happy to test other DEs if that would be helpful. I'll do some more tinkering on my other systems (including my server which runs debian) and see if I can find anything else to add.
Thanks a million, this is huge!
-
I could see it flashing from a graphics quirk or so - but resetting the input location suggests something else is going on, maybe Theater View is being restarted all the time? A log might help (try to keep it short, start MC, enter Theater View, see it flash a few times, and quit).
I haven't actually tried it on anything but Intel GPUs yet, but somehow it doesn't feel like a graphics change can cause this, but we'll find out!
For the Playing Now issue - did you try clicking into the window after pressing stop?
I couldn't reproduce any "freeze", but for some reason it does appear to lose input focus. Unfortunately the window and focus management on Linux are a bit of a mistery to me. Maybe Bob can help?
-
Holy cow now we're talking!
I haven't upgraded to 22 yet, but it just got a little more urgent :-)
-
I could see it flashing from a graphics quirk or so - but resetting the input location suggests something else is going on, maybe Theater View is being restarted all the time? A log might help (try to keep it short, start MC, enter Theater View, see it flash a few times, and quit).
I haven't actually tried it on anything but Intel GPUs yet, but somehow it doesn't feel like a graphics change can cause this, but we'll find out!
I'll test later and send some logs. I have two NVidia systems running Arch, so I can see if the behavior is identical on the other one too.
For the Playing Now issue - did you try clicking into the window after pressing stop?
I couldn't reproduce any "freeze", but for some reason it does appear to lose input focus. Unfortunately the window and focus management on Linux are a bit of a mistery to me. Maybe Bob can help?
Good catch, it is just losing focus on stop. Clicking the interface brings control back. That actually reminds me of some very strange behavior I've been seeing on stop with my raspberry pi's. Frequently when a playlist finishes (i.e. stops) I'll see a focus change on my raspberry pi kiosk systems. It also prevents the screen from turning off until I interact with it again. I always assumed it was something flaky with the Pi's and the Pi touch display, but it may be related to this since both involve focus shenanigans on stop.
Two more reports:
1. I know you said obsidian was the only tested skin; I typically use Noire, so I did some testing. It appears to work well except that the backgrounds are extremely washed out. It looks like it's running in a limited color gamut instead of 0-255, or the gamma is way too high or something.
2. It doesn't appear to respect the theater view scaling setting (or any other scaling setting for that matter). That makes it a little hard to use on a hi DPI screen, but I'm sure that will come in time.
Great work, this is awesome.
-
1. I know you said obsidian was the only tested skin; I typically use Noire, so I did some testing. It appears to work well except that the backgrounds are extremely washed out. It looks like it's running in a limited color gamut instead of 0-255, or the gamma is way too high or something.
I can't really reproduce this. I loaded Noire in DX and in OpenGL (both on Windows), and both look perfectly identical. I also opened the same view on my Linux box and it looks the same there (as it happens it has the same monitor as well).
It should always output full range and use the desktop gamma. I don't suppose there is a system or screen difference or something like that?
Noire is kind of meant to look a bit washed out as it has a grey overlay over the background images.
2. It doesn't appear to respect the theater view scaling setting (or any other scaling setting for that matter). That makes it a little hard to use on a hi DPI screen, but I'm sure that will come in time.
Scale seems to work here. You might need to restart MC for that to fully catch on.
-
I can't really reproduce this. I loaded Noire in DX and in OpenGL (both on Windows), and both look perfectly identical. I also opened the same view on my Linux box and it looks the same there (as it happens it has the same monitor as well).
It should always output full range and use the desktop gamma. I don't suppose there is a system or screen difference or something like that?
I tested in windows and Linux on the same machine (dual boot) and reproduced it. So I can rule out the screen and hardware differences. I'll try on a few more boxes and see what I get.
Noire is kind of meant to look a bit washed out as it has a grey overlay over the background images.
This is definitely different than the normal Noire grey, this isn't a subtle grey.
Scale seems to work here. You might need to restart MC for that to fully catch on.
I'll test that; can you confirm it's the theater view scale setting that it respects and not one of the other scale settings? I thought I restarted with no difference. It definitely ignores the DE scaling setting.
-
With the URL fix by JimH, I finally downloaded and installed 2.0.37 beta. No luck with "Theatre View". All I got was a large white screen on an Acer X34 Predator monitor (3440 x 1400) running Mint 18 64 bit. I'm also using a new EVGA 1080 FTW video card.
GLXinfo:
server glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1080/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 370.28
OpenGL core profile shading language version string: 4.50 NVIDIA
When I first ran Theatre View I noticed the default skin was "Acaju". I thought that might be the problem based on Hendrick's initial post, so I changed it to "Obsidian" but that didn't work either. I didn't notice any screen flashing as noted by mwillems.
-
This is definitely different than the normal Noire grey, this isn't a subtle grey.
This is how it looks for me (both on original Windows and Linux), which doesn't seem very subtle:
http://i.imgur.com/JuOlLWH.jpg
I'll test that; can you confirm it's the theater view scale setting that it respects and not one of the other scale settings? I thought I restarted with no difference. It definitely ignores the DE scaling setting.
Yes, same scale setting as Windows.
-
GLXinfo:
server glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1080/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 370.28
OpenGL core profile shading language version string: 4.50 NVIDIA
I haven't tested on NVIDIA yet, but I will do that next week. We'll see whats going on. A log file might help in the meantime.
-
I can't really reproduce this. I loaded Noire in DX and in OpenGL (both on Windows), and both look perfectly identical. I also opened the same view on my Linux box and it looks the same there (as it happens it has the same monitor as well).
It should always output full range and use the desktop gamma. I don't suppose there is a system or screen difference or something like that?
Noire is kind of meant to look a bit washed out as it has a grey overlay over the background images.
Ok I figured this out, this one is user error or possibly a difference in defaults. All of my JRiver installs have the "theme background" for Noire set to "black" rather than the skin image. I don't recall ever making that change, but some of these installs were set up years ago with library imports between major versions, so it's possible I did and forgot about it or that setting is an old default or is inherited from the server on the windows side. In any case your note about "supposed to look that way" had me look harder at the settings and that setting was set to skin image on my Linux install which created the grey wash.
Thanks for the tip, this one is resolved.
Scale seems to work here. You might need to restart MC for that to fully catch on.
Ok, scale does change between restarts, that was the trick. But there's an issue: on windows theater view scale takes into account (or is applied on top of) the windows system scaling, whereas the Linux version ignores system scaling. This confused me because the theater view text was still pretty small on a retina display at 200%, whereas on windows (on the same machine) theater view text was huge at that scale. So JRiver's scale setting currently tops out at 200% (larger scales aren't accepted), but that's not really big enough without being able to leverage system scaling.
For example, on the windows side with this display, I use 125% theater view scaling on top of 200% windows scaling, effectively getting 250% scaling, if you see what I mean. It's a touch screen and some interface elements are too small to touch with flat 200% on Linux (and might be hard to see across the room on a larger screen). So I'd like to petition for either taking into account Linux desktop scaling (which seems challenging given that everyone does it differently) or allowing scale factors above 200%.
I haven't been able to do any more NVidia testing, but I'll have more tomorrow and some logs.
-
Ok, scale does change between restarts, that was the trick. But there's an issue: on windows theater view scale takes into account (or is applied on top of) the windows system scaling, whereas the Linux version ignores system scaling. This confused me because the theater view text was still pretty small on a retina display at 200%, whereas on windows (on the same machine) theater view text was huge at that scale. So JRiver's scale setting currently tops out at 200% (larger scales aren't accepted), but that's not really big enough without being able to leverage system scaling.
I don't think we do any system scale things on Linux yet for any parts of the interface. This should come automatically once that happens, I would think. Sorry, out of scope for me right now. Maybe Bob has some plans to address this. 4K on Linux is probably not the highest on his list, however.
As a band-aid I could allow higher scale values if that helps.
-
As a band-aid I could allow higher scale values if that helps.
That would work fine for me (i.e. if I could set 250% or 300% or something). I appreciate the help ;D
-
This is really excellent. Just watched a show with the family in Linux theater view, and they didn't even realize anything was different. IR Remote appears to be working fine. Good stuff.
I've attached a log reproducing the NVidia flashing (I let it flash three or four times before switching back to standard view). It does appear to be starting over (over and over); I noticed on my working systems that there's a white flash when theater view first starts. It may be related to vsync as changing the FPS setting for theater view changes the frequency of the white flash. I tried disabling flipping and sync to vblank, and that didn't seem to affect anything. I'm using the Gnome desktop environment if that matters.
Two minor reports:
1) The Gizmo theater view remote does not appear to work for navigation with the Linux theater view; I recognize that was kind of a "fringe" feature, it just seemed like something worth testing as I suspect that not everyone will have as easy a time with their IR remote as I have.
2) The time displayed is not formatted nicely (like on Windows theater view). It shows a leading "0" with single digit hours, and shows seconds. Apologies if there's a way to tweak that in the theme settings, but I couldn't find one, and it's definitely different than the windows default.
But those are just nits. On Intel graphics this is already impressively solid.
-
Off topic, but how long before TV functionality is working on Linux and I get to rid my HTPC of Windows forever? ;D I love that we're getting closer...
-
I've attached a log reproducing the NVidia flashing (I let it flash three or four times before switching back to standard view). It does appear to be starting over (over and over); I noticed on my working systems that there's a white flash when theater view first starts. It may be related to vsync as changing the FPS setting for theater view changes the frequency of the white flash.
Its definitely restarting Theater View all the time. This sounds odd, not sure what could be triggering this, but guess I'll need to setup some more advanced linux system then this plain Debian with Xfce on Intel. Not even a compositor on here!
1) The Gizmo theater view remote does not appear to work for navigation with the Linux theater view; I recognize that was kind of a "fringe" feature, it just seemed like something worth testing as I suspect that not everyone will have as easy a time with their IR remote as I have.
Not really sure how that works at all. Its probably a generic linux thing that it doesn't work.
2) The time displayed is not formatted nicely (like on Windows theater view). It shows a leading "0" with single digit hours, and shows seconds. Apologies if there's a way to tweak that in the theme settings, but I couldn't find one, and it's definitely different than the windows default.
Locale aware time formatting is annoying on Linux. But this is generic MC code anyway, not Theater View specific. It just uses the default time format that MC provides.
There doesn't appear to be a strftime token that prints hours and minutes only in a locale specific way. And I also could not even figure out how to query the locale if there is a 12 or 24 hour clock. :(
Forcing a hours:minutes 24 hour clock would be easy, or a 12 hour clock of the same setup. But 24 would confuse you poor americans and 12 would enrage myself. :)
-
works fine on nvidia here, an uptodate debian testing box running with kde5 with an nvidia gtx950 in it (367.44 drivers)
no freeze on pressing stop in playing now either, agree it does lose keyboard input (which generally seems slightly unreliable from what I see)
-
thought I'd try it on another system that just has an intel gpu (an i3 540 so a bit old)
glxinfo says
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Desktop
OpenGL version string: 2.1 Mesa 12.0.3
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 12.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
so I suppose it's too old for this, just thought I'd mention that turning on theater view on this box just immediately crashes the process. I guess some validation is required there.
-
works fine on nvidia here, an uptodate debian testing box running with kde5 with an nvidia gtx950 in it (367.44 drivers)
no freeze on pressing stop in playing now either, agree it does lose keyboard input (which generally seems slightly unreliable from what I see)
That's interesting as it suggests that it may be a Gnome window manger/compositor (mutter) issue. The other fellow who reproduced my issue is running Cinnamon which also relies on mutter. There are a handful of other mutter dependent DEs as well, but xfce and kde are not.
So I'll try a few different DEs on that system as a test. Thanks for the clue Matt.
EDIT: It was a nice theory, but I just tested with xfce and KDE on my Arch box with the NVidia 970 and I get the same flashing. So it doesn't appear to be DE specific in my case, unfortunately.
Locale aware time formatting is annoying on Linux. But this is generic MC code anyway, not Theater View specific. It just uses the default time format that MC provides.
There doesn't appear to be a strftime token that prints hours and minutes only in a locale specific way. And I also could not even figure out how to query the locale if there is a 12 or 24 hour clock. :(
Forcing a hours:minutes 24 hour clock would be easy, or a 12 hour clock of the same setup. But 24 would confuse you poor americans and 12 would enrage myself. :)
Maybe this could this just be left up to the user? There's already user configurable time display stuff in MC for, for example, the time to run of a given song or video in the top bar of standard view. A simple 12 or 24 hour hour clock toggle would probably solve the issue, and that's the way many Linux native software packages address the issue (e.g. the Gnome desktop offers a toggle, doesn't bother trying to autodetect).
-
I have another idea - do you have multiple monitors on those systems with issues? Monitor information is barely handled at all on linux, so it'll likely screw up something there and think Theater View needs resizing.
It *might* work if you manage to open it on the other screen, as its likely just confused which screen its running on.
It seems thats a topic we should handle better, but admittedly most things running Theater View on a TV or so would be limited to a single screen. Maybe I can get bob interested in this.
-
I have another idea - do you have multiple monitors on those systems with issues? Monitor information is barely handled at all on linux, so it'll likely screw up something there and think Theater View needs resizing.
It *might* work if you manage to open it on the other screen, as its likely just confused which screen its running on.
It seems thats a topic we should handle better, but admittedly most things running Theater View on a TV or so would be limited to a single screen. Maybe I can get bob interested in this.
It is a dual monitor system (A TV and a small nearby "control" display). I'll test on a single display NVidia system and see if I get the same results. As I said the display view OSD is kind of flaky on that system so better general handling would be nice.
A fresh bug report: after certain amount of uptime the roller menus go blank and stay that way until you leave theater view and come back. This used to happen on the windows side occasionally, but got fixed for me in MC21.
-
With Debian Testing / Xfce Theatherview works very well. Thanks for the great work.
Is there a way to turn off transparency? The panels of the main screen show through. Which is disturbing.
The right click on some items sometimes leads to an immediate MC crash. (MC closes immediately)
System info:
uname -a
Linux sparkyxfce 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux~$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4~$ glewinfo
GLEW version 2.0.0
Reporting capabilities of display , visual 0x2b
Running on a GeForce GTX 750 Ti/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 4.5.0 NVIDIA 367.44 is supported
glewinfo |grep GL_VERSION
GL_VERSION_1_1: OK
GL_VERSION_1_2: OK
GL_VERSION_1_2_1: OK
GL_VERSION_1_3: OK
GL_VERSION_1_4: OK
GL_VERSION_1_5: OK
GL_VERSION_2_0: OK
GL_VERSION_2_1: OK
GL_VERSION_3_0: OK
GL_VERSION_3_1: OK
GL_VERSION_3_2: OK
GL_VERSION_3_3: OK
GL_VERSION_4_0: OK
GL_VERSION_4_1: OK
GL_VERSION_4_2: OK
GL_VERSION_4_3: OK
GL_VERSION_4_4: OK
GL_VERSION_4_5: OK
-
The transparency should hopefully be gone in a future build. I didn't particularly request a buffer with transparency, but it occured to me that I could still get one, since thats not forbidden, so I need to render the background color fully opaque to compensate.
I'll check on right clicks. Can't say I really tried to right-click in theater view with the mouse.
-
Mysterious - :-[
On Debian-Testing Cinnamon (dual-boot machine) on Theater-View there is only a white screen.
The output of glewinfo and glxinfo is exactly identical
uname -a
Linux sparkycinnamon 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux
-
I set up my NVIDIA box using Cinnamon this morning and unfortunately it "just works" there. Maybe post a log file? That would at least tell me how far it got.
I can try to switch to debian-testing instead of jessie, maybe the newer software makes a difference.
One good news - I could reproduce the right-click crash reported above, so I'll work on that.
Edit:
I get the white screen with testing, i'll investigate.
-
Tested on my debian Jessie i386 system at home.
I get a white screen.
It's using the intel graphics and has the required versions of OpenGL and GLEW.
VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
[ 434.331] (==) AIGLX enabled
[ 434.331] (II) LoadModule: "intel"
[ 434.331] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 434.333] (II) Module intel: vendor="X.Org Foundation"
[ 434.333] compiled for 1.15.99.904, module version = 2.21.15
[ 434.334] Module class: X.Org Video Driver
[ 434.334] ABI class: X.Org Video Driver, version 18.0
[ 434.334] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, HD Graphics,
HD Graphics 2000, HD Graphics 3000, HD Graphics 2500,
HD Graphics 4000, HD Graphics P4000, HD Graphics 4600,
HD Graphics 5000, HD Graphics P4600/P4700, Iris(TM) Graphics 5100,
HD Graphics 4400, HD Graphics 4200, Iris(TM) Pro Graphics 5200
-
I think I got the white screen issue fixed, the window had some wrong attributes, which apparently interacted badly with some window managers. At least my Debian-testing Cinnamon now shows an image.
-
Great ! I'm waiting anxiously for the next build
-
A new build is available now (22.0.37-10). Bob has been working on multi-monitor things, and for Theater View purposes it should work now, but some issues are still in there.
Otherwise, the white-screen issue is hopefully solved, the right-click menus should work, and various other changes.
Please let us know how it goes!
-
A new build is available now (22.0.37-10). Bob has been working on multi-monitor things, and for Theater View purposes it should work now, but some issues are still in there.
Otherwise, the white-screen issue is hopefully solved, the right-click menus should work, and various other changes.
Please let us know how it goes!
Most excellent! Theater view is now working on my dual monitor nvidia setup, and the OSD is actually stable in display mode! I'll keep testing, but that's a big leap forward for me right there.
-
Great news! Thanks.
-
Most excellent! Theater view is now working on my dual monitor nvidia setup, and the OSD is actually stable in display mode! I'll keep testing, but that's a big leap forward for me right there.
I had a feeling the multi-monitor support would help with the OSD...
-
Still no joy on my i386 Jessie box though.
White screen as usual and the top level screen positioning is very flakey...
-
Still no joy on my i386 Jessie box though.
White screen as usual and the top level screen positioning is very flakey...
Fixed in 22.0.39-9 (i386)
The Theater View Skins were missing from the .dpkg
-
I think I got the white screen issue fixed, the window had some wrong attributes, which apparently interacted badly with some window managers. At least my Debian-testing Cinnamon now shows an image.
Hendrik, you did it. :) I can also confirm that I no longer get a white screen on my Predator x34 monitor as previously reported. I forgot how much I missed Theatre View. Great work.
-
Sounds good!
After the Mac version is also available I'll work on implementing some of the missing features outlined in the first post. Still a long way to finish everything, but we'll get there!
Its really been good to see how well the first version worked everywhere, which means the overall design works well, which is the most important part. All big failures were from linux-specific window management problems, not Theater View itself! :)
-
Its really been good to see how well the first version worked everywhere, which means the overall design works well, which is the most important part. All big failures were from linux-specific window management problems, not Theater View itself! :)
A massive thanks for your work, Hendrik!
-
Yes - it also works in Debian Stretch / Cinnamom. Thanks for this work. :)
The crash during a right click is still ahead:
Theater View ---> Audio ---> Artist ---> right click on any icon gives this (systemd - protocol):
Mediacenter22 [21641]: segfault at 6500000072 ip 00007fc4b4f12b17 sp 00007ffe00cc8f70 error 4 in libJRImage.so [7fc4b4e0c000 + 451000]
-
Yes - it also works in Debian Stretch / Cinnamom. Thanks for this work. :)
The crash during a right click is still ahead:
Theater View ---> Audio ---> Artist ---> right click on any icon gives this (systemd - protocol):
Mediacenter22 [21641]: segfault at 6500000072 ip 00007fc4b4f12b17 sp 00007ffe00cc8f70 error 4 in libJRImage.so [7fc4b4e0c000 + 451000]
Same here when I test on debian x64 gnome.
-
Same here when I test on debian x64 gnome.
Just doesn't want to crash for me anymore. Bob can you get me a stack trace or something?
-
Just doesn't want to crash for me anymore. Bob can you get me a stack trace or something?
Will try to get one today.
I get different behavior on i386 at home, it doesn't crash on a right click but does hang the screen in TV mode. I have to switch to a different VT and hard kill MC.
-
Personally I just use it with a remote control, not once have I used the context menu outside of testing. You guys use the weirdest things! :P
We do think we finally found the reason for the crash, though!
-
The next build will implement the file info images and the PiP window - thats basically all I personally use of Theater View now!
Next up are the 3D views and rotation animations (done those). After that all the major things should be done, and only the tweaking and fiddling remains.
-
The next build will implement the file info images and the PiP window - thats basically all I personally use of Theater View now!
Next up are the 3D views and rotation animations. After that all the major things should be done, and only the tweaking and fiddling remains.
Thanks, job well done.
George
-
The next build will implement the file info images and the PiP window - thats basically all I personally use of Theater View now!
Next up are the 3D views and rotation animations (done those). After that all the major things should be done, and only the tweaking and fiddling remains.
This is fantastic. Thanks so much for your efforts, Hendrik.
-
I started a thread on IR Receivers and Remotes (https://yabb.jriver.com/interact/index.php/topic,107860.msg748481.html#msg748481).
-
I've finally sorted out a driver bug I've been facing the past couple of months so I can now fire up Theater View on Fedora 25. Awesome!
The only major thing I've noticed after a couple of minutes is that after exiting Theater View, the MC standard view will cover the taskbar and I haven't figured out a way yet to get it back to its normal windowed size.
-
I've finally sorted out a driver bug I've been facing the past couple of months so I can now fire up Theater View on Fedora 25. Awesome!
The only major thing I've noticed after a couple of minutes is that after exiting Theater View, the MC standard view will cover the taskbar and I haven't figured out a way yet to get it back to its normal windowed size.
I can confirm this, I see the same behavior with Gnome on Arch. The only fix appears to be to close MC and restart it.
To elaborate, standard view appears maximized after leaving theater viw, but covers the taskbar and will not respond to any attempts to restore it's windowed state or re-maximize it (whether using buttons, hotkeys, etc.). Minimize works, but if you refocus it after minimize it still occupies the whole screen and covers the task bar.
-
The next build should finally introduce Anti-Aliased rendering in Theater View on Linux (requires OpenGL 3.0+ or the ARB_framebuffer_object extension)
Is the Standard View size bug still happening in recent versions for you guys with all the window/screen handling changes?
-
On 23.0.41, after opening Theater View, I just get a white screen after a few seconds.
TV opens, it works (I can open audio or walk through the menus) but regardless, after a few seconds, it just turns white.
I can't exit, close or blindly try to pick something, it stays white. I have to force quit.
I am on Arch Linux, fully updated, with official and latest Nvidia drivers. I have VDPAU configured and direct rendering working. As far as I can tell I have all 32-bit libraries for nvidia, hardware video decoding and generic opengl rendering installed too.
Any ideas on how to fix or troubleshoot? Anyone else seen this?
Thanks.
-
I assume this didn't happen with 36?
-
I don't know, I never tried Theater View on previous versions.
-
Are you using the 32-bit or 64-bit version of MC? If the latter, you won't need the 32-bit libraries for Nvidia.
I'll see if I can test this here in a couple hours.
-
64-bit.
I need those libraries for other things as well.
-
Not really a linux guy. But I loaded debian (stretch xfce) on a very old netbook this morning amd 1ghz cpu 4g ram and a 126 ssd. JRM passmark is 460.
Believe it or not, much to my surprise (audio) theater view is working. Very slowly, but its working. Pretty amazing its running on such old technology. Think I'm going to roll my own NUC ID and hopefully speed things up a bit.
Keep up the good work. Kudos!
-
Good to hear. You could probably speed up Theater View in the options for framerate under Advanced.
-
Good to hear. You could probably speed up Theater View in the options for framerate under Advanced.
What a invaluable tip! I had to turn video back on - audio only off - for the framerate option to show up. Set it to 10 from 0 things are snappier now. Thank you.
Need to try this on my PI install after this song.
-
Must be placebo at work, because those options don't do anything for OpenGL Theater View in Linux. :D
-
Must be placebo at work, because those options don't do anything for OpenGL Theater View in Linux. :D
Aren't you a sunday afternoon party pooper ;)
Tried it on my RPI install, changed it from 60 to 30 with no effect, not even placebo effect.
Back to buying a NUC5CPYH for viewing artist art on the TV and the RPI as an endpoint.
-
Aren't you a sunday afternoon party pooper ;)
Tried it on my RPI install, changed it from 60 to 30 with no effect, not even placebo effect.
Back to buying a NUC5CPYH for viewing artist art on the TV and the RPI as an endpoint.
I've been using Theater View more and more on the Id I have at home. It's becoming my default interface.
Been playing with it with a Media Center Remote. It works well but for me the remote function in JRemote is easier.
-
I'm from the age of vinyl records kept in album jackets. Theater view is my 21st century album jacket. Typically, I play a song with play doctor and let it play using a wireless mouse for pausing/skipping tracks and the amplifiers remote for volume. Mine is a simple life that doesn't include the video/TV constantly playing in our family room.
-
Tried it on my RPI install, changed it from 60 to 30 with no effect, not even placebo effect.
Trying to optimize it for the RPi is still on the TODO list, however its unclear if we can make it work much better on such a tiny device.
-
Trying to optimize it for the RPi is still on the TODO list, however its unclear if we can make it work much better on such a tiny device.
This is just an idea; I would like to know if anybody thinks it has merit.
I have minimserver running on another machine in my network. Do you think theater view would run better using two PI's. One as the control point in theater mode and another as the endpoint?
I would have to buy another PI3 to try this; or use a PI Zero as a endpoint.
-
I just setup an Intel NUC with Fedora and got jriver running. Thanks for the good posts. However, when I switch to Theater View it comes back indicating it could not find any Theater View skins.
Any light?
Disregard. I found that somehow my user Theater Skin section was missing the main.xml in each skin. I just copied from /usr/lib and it is working nice now. Thanks for the log function. Although I dont know how that file was missing while all others in same dir were present.
-
Hello,
Happy to see the Linux developments. I'm adding a Linux based JRiver Media Center to my multimedia solution. I'm choosing Linux because it has built-in kernel support for my Hiface Evo. This is a critical component in my digital audio chain (A windows 10 update last year caused a BSOD with the WASAPI Hiface driver).
Unfortunately I have an issue with the Display and Theater view (see below).
Did someone see this behavior on his system or know how to resolve?
Issue
When I switch from Standard to Theater or Display view, the gnome display manager starts writing messages to logfiles (messages, syslog etc) constantly. These logfiles grow about 1TB in total every day resulting in disk space issues. When I switch back to Standard view, this behavior stops.
Messages are like: /usr/lib/gdm3/gdm-x-session[573]: (II) modeset(0): Modeline "1440x240"x0.0 27.00 1440 1478 1602 1716 240 244 247 262 -hsync -vsync (15.7 kHz e)
System details
Motherboard: ASRock J4205 - Mini-ITX
Processor: Intel Apollo Lake - Pentium QuadCore - 4x2,6GHz (14nm)
Video (onboard): Intel HD Graphics 500 - 750GHz
Memory: 8 GB
SSD: 60 GB
OS: Debian Stretch (Jessie does not support this hardware)
Any suggestions are welcome.
Kind regards,
Erik
-
Hello,
Happy to see the Linux developments. I'm adding a Linux based JRiver Media Center to my multimedia solution. I'm choosing Linux because it has built-in kernel support for my Hiface Evo. This is a critical component in my digital audio chain (A windows 10 update last year caused a BSOD with the WASAPI Hiface driver).
Unfortunately I have an issue with the Display and Theater view (see below).
Did someone see this behavior on his system or know how to resolve?
Issue
When I switch from Standard to Theater or Display view, the gnome display manager starts writing messages to logfiles (messages, syslog etc) constantly. These logfiles grow about 1TB in total every day resulting in disk space issues. When I switch back to Standard view, this behavior stops.
Messages are like: /usr/lib/gdm3/gdm-x-session[573]: (II) modeset(0): Modeline "1440x240"x0.0 27.00 1440 1478 1602 1716 240 244 247 262 -hsync -vsync (15.7 kHz e)
System details
Motherboard: ASRock J4205 - Mini-ITX
Processor: Intel Apollo Lake - Pentium QuadCore - 4x2,6GHz (14nm)
Video (onboard): Intel HD Graphics 500 - 750GHz
Memory: 8 GB
SSD: 60 GB
OS: Debian Stretch (Jessie does not support this hardware)
Any suggestions are welcome.
Kind regards,
Erik
What's your desktop size?
Do you have multiple monitors and if so which is MC on?
-
I've only one 55 Inch OLED 4K TV attached to the system. I've tried resolutions 1920x1080 (HD) and 3840x2160 (Ultra HD). Both show the same behavior.
-
I've only one 55 Inch OLED 4K TV attached to the system. I've tried resolutions 1920x1080 (HD) and 3840x2160 (Ultra HD). Both show the same behavior.
This looks weird:
modeset(0): Modeline "1440x240"x0.0
The only references I could find to this made it look like either a gdm bug or installation issue. The 0.0 is supposedly the frame rate. Maybe you shouldn't be using modsetting?
Unfortunately this is where linux becomes problematic, the variety of XServer drivers, vendor dependent stuff, etc.
-
Modeline settings are generated dynamically by the kernel using EDID data from TV. It's not a manual config file. Videos are played well. The problem is the hundreds thousands of modeset messages that are generated in logfiles when I switch to Theater/Display View. When I use the Gnome player Totem in full screen mode, these messages are not generated. So the problem is very specific to JRiver MC Theater/Display view.
-
Modeline settings are generated dynamically by the kernel using EDID data from TV. It's not a manual config file. Videos are played well. The problem is the hundreds thousands of modeset messages that are generated in logfiles when I switch to Theater/Display View. When I use the Gnome player Totem in full screen mode, these messages are not generated. So the problem is very specific to JRiver MC Theater/Display view.
That may be true however since they appear to only happen on your system I'm not aware of anything we can change on this end to fix it for you.
-
I guess that the issue is the following:
- When JRiver MC switches to Theater Mode or Display mode it sets the screen resolution to the Desktop resolution (as configured in Tree&View). This goes well
- I guess that it also tries to query the available screen resolutions
- For some reason availabe screen resolutions are not returned by my system (they are not shown in Options>Tree&View>Full Screen>Resolution)
- JRiver MC keeps trying forever (loop?) until I switch back to the standard display
- This triggers randr calls again and again resulting in thousands modeline messages in the logfile
Assuming that I'm right, would it be possibe to stop JRiver MC to query available screen resolutions forever?
-
Perhaps it might be more sensible to figure out why your system fails to report any available resolutions?
-
Maybe. How does media center query the resolutions on Linux (e.g. read a config file or perform a system call)?
Maybe setting the resolutions manually is a workaround. What is the format of parameter value "Full Screen Resolution="?
"~\.jriver\Media Center 23\Settings\User Settings.ini":
[Zones\\0\\Display]
Full Screen Monitor=i:"0"
Full Screen Resolution=""
Windowed Always On Top=i:"1"
Windowed Placement=b:"LAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE8CAADlAQAAXwIAAK0CAAA\="
-
Maybe. How does media center query the resolutions on Linux (e.g. read a config file or perform a system call)?
First MC calls:
XRRGetScreenResources
to get the number of screens and then for each screen it does:
XRRGetCrtcInfo
to get the height and width.
If this fails it drops back to:
XDisplayWidth and XDisplayHeight to get the primary display width and height.
Seems like xrandr is broken on your system.
-
First MC calls:
XRRGetScreenResources
to get the number of screens and then for each screen it does:
XRRGetCrtcInfo
to get the height and width.
If this fails it drops back to:
XDisplayWidth and XDisplayHeight to get the primary display width and height.
Seems like xrandr is broken on your system.
It seems like in your case xrandr is reporting 0 screens connected which isn't handled nicely by MC before the fallback to the non-xrandr method of getting the screen size.
I'm guessing that's generating all of those messages you described.
I made a change in the next build such that if xrandr returns 0 screens found it will just go on to the non-xrandr method instead of trying to get the screens over and over.
I
-
So recently got tired of troubleshooting why Windows 10 broke my audio during an update. I decided to wipe my OS drive and load Linux on the same HTPC I've been flawlessly running for 5 or 6 years now. I upgrade to the Linux version of JRiver 28 and so far everything is working except this white screen issue.
Here's what happens. I select "Theater View" and see the theater view screen for a split second and then a white screen pops up over top of it. I can hit "Shift F-11" and it'll go back to standard view. If I select "Cover View" or "Display View" it will take me there, and then if I hit "Shift F-11" it takes me to Theater view and the white screen is gone. Any ideas?
I'm thinking this might be a glitch in the software but what do I know? I am not a programmer and I don't know crap about Linux yet, I'm an audio guy. I do know that we loaded Linux Mint. I can also say that I have tried everything I could find on this with white screen, black screen, blank screen. I've tried all of the settings in JRiver and with monitor settings. I tried 3 different video cards both NVIDIA and Radeon with the same results.
Oh, and for some reason, video is choppier now than before. Used to be much smoother when fading from one screen to another.
Thanks in advance,
Duane
-
So recently got tired of troubleshooting why Windows 10 broke my audio during an update. I decided to wipe my OS drive and load Linux on the same HTPC I've been flawlessly running for 5 or 6 years now. I upgrade to the Linux version of JRiver 28 and so far everything is working except this white screen issue.
Here's what happens. I select "Theater View" and see the theater view screen for a split second and then a white screen pops up over top of it. I can hit "Shift F-11" and it'll go back to standard view. If I select "Cover View" or "Display View" it will take me there, and then if I hit "Shift F-11" it takes me to Theater view and the white screen is gone. Any ideas?
I'm thinking this might be a glitch in the software but what do I know? I am not a programmer and I don't know crap about Linux yet, I'm an audio guy. I do know that we loaded Linux Mint. I can also say that I have tried everything I could find on this with white screen, black screen, blank screen. I've tried all of the settings in JRiver and with monitor settings. I tried 3 different video cards both NVIDIA and Radeon with the same results.
Oh, and for some reason, video is choppier now than before. Used to be much smoother when fading from one screen to another.
Thanks in advance,
Duane
Look in the Video settings and try the JRVR renderer with Hardware decoding enabled and see if that makes any difference.
Note that the nouveau x server has a lot of issues.
-
I checked those settings and nothing made any difference.
I googled the nouveau x server and it seems to be in reference to NVIDEA drivers. I am using a Radeon card so I'm not sure if that matters.
It's strange that there is a way to get to Theater View but not directly by clicking on it.
-
Please turn on logging (Help->Logging)
Attempt to go into Theater View to generate the error.
Return from Theater View, stop the logging and email to log to
bob (at) jriver (dot) com.
Thanks.