Print

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

[Hendrik]

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!

[JimH]

I changed the topic title from Feedback to NEW.  This is a big deal.  Thanks, Hendrik.  Well done.

[mwillems]

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!

[Hendrik]

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?

[imugli]

Holy cow now we're talking!

I haven't upgraded to 22 yet, but it just got a little more urgent :-)

[mwillems]

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.

[Hendrik]

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.

[mwillems]

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.

[Rizlaw]

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.

[Hendrik]

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.

[Hendrik]

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.

[mwillems]

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.

[Hendrik]

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.

[mwillems]

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 

[mwillems]

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.

[imugli]

Off topic, but how long before TV functionality is working on Linux and I get to rid my HTPC of Windows forever?  I love that we're getting closer...

[Hendrik]

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.

[mattkhan]

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)

[mattkhan]

thought I'd try it on another system that just has an intel gpu (an i3 540 so a bit old)

glxinfo says

Code: [Select]

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.

[mwillems]

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).

[Hendrik]

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.

[mwillems]

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.

[geier22]

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:

Code: [Select]

uname -a
Linux sparkyxfce 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux

Code: [Select]

~$ 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

Code: [Select]

~$ 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

[Hendrik]

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.

[geier22]

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

Code: [Select]

uname -a
Linux sparkycinnamon 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux


[Hendrik]

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.

[bob]

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

[Hendrik]

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.

[geier22]

Great ! I'm waiting anxiously for the next build

[Hendrik]

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!

[mwillems]

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.

[JimH]

Great news!  Thanks.

[bob]

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...

[bob]

Still no joy on my i386 Jessie box though.
White screen as usual and the top level screen positioning is very flakey...

[bob]

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

[Rizlaw]

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.

[Hendrik]

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!

[imugli]

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!

[geier22]

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):

Code: [Select]

Mediacenter22 [21641]: segfault at 6500000072 ip 00007fc4b4f12b17 sp 00007ffe00cc8f70 error 4 in libJRImage.so [7fc4b4e0c000 + 451000]

[bob]

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):

Code: [Select]

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.

[Hendrik]

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?

[bob]

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.

[Hendrik]

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!

We do think we finally found the reason for the crash, though!

[Hendrik]

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.

[Ekpen]

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

[imugli]

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.

[JimH]

I started a thread on IR Receivers and Remotes.

[BryanC]

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.

[mwillems]

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. 

[Hendrik]

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?