Topic: Window refocus hangs (Read 11020 times)

mikeza · « **on:** February 08, 2016, 01:18:35 pm »

Hi all,

I installed the newest amd64 jriver release on Arch and am using the newest version of GNOME. It took a bit to get things working, but the program is running pretty smoothly.

Recently, when I move from another application back to J River, it takes a long time for the window to re-register focus, i.e. the gui is updating but will not take commands, however, given enough time, all the commands will go through at once. Once it's "refocused" for a while, it functions as normal.

Elements respond to a mouseover but not to a touchpad click.

Any suggested fixes?

Happy to provide more information.

mikeza · « **Reply #1 on:** February 16, 2016, 06:46:35 pm »

bump.

The GUI is incredibly laggy. If I send a lot of mouse clicks while it's in this unresponsive state it will begin to receive them all at once and things like the time of the current song will jump 30 seconds at a time. Playback is also inconsistent.

If someone points me in the right way I can put in work figuring out what's going on, I've already attempted disabling extraneous features, server, etc. and am looking through the logs for hints but I'm not familiar enough with X11 and JRiver's GUI base to really troubleshoot. Any suggestions would be great.

Awesome Donkey · « **Reply #2 on:** February 16, 2016, 06:48:54 pm »

Hmmm, can't say I've noticed any of these issues on Ubuntu 15.10 or in my Debian or Mint VMs.

JimH · « **Reply #3 on:** February 16, 2016, 06:57:41 pm »

What version are you using? What sort of hardware?

Awesome Donkey · « **Reply #4 on:** February 16, 2016, 07:03:16 pm »

Open a Terminal and start Media Center using mediacenter21 (if you're using MC21) and post any errors here.

mikeza · « **Reply #5 on:** February 16, 2016, 10:24:24 pm »

Thanks for the response guys. You would definitely notice if you were encountering it -- it's borderline unusable; response time is on the order of minutes.

Running it from the terminal doesn't produce any information (except that it finds 0 devices).

Interesting... the lag only occurs during playback It also appears that the longer it has been playing, the worse the lag. I'll play with my playback settings and see if I can resolve it. edit: nothing seems to be having much of an effect

Here's some system info

Code: [Select]

Media Center 21.0.39

System:    Host: localhost Kernel: 4.4.1-2-ARCH x86_64 (64 bit)
           Desktop: Gnome 3.18.3 Distro: Arch Linux
Machine:   Mobo: Acer model: Storm2 v: V2.05
           Bios: Insyde v: V2.05 date: 09/25/2013
CPU:       Dual core Intel Core i7-4500U (-HT-MCP-) cache: 4096 KB 
           clock speeds: max: 3000 MHz 1: 799 MHz 2: 799 MHz 3: 799 MHz
           4: 799 MHz
Graphics:  Card: Intel Haswell-ULT Integrated Graphics Controller
           Display Server: N/A driver: intel Resolution: 80x24
Audio:     Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel
           Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.4.1-2-ARCH
Network:   Card: Intel Wireless 7260 driver: iwlwifi
           IF: wlp1s0 state: up mac: 5c:51:4f:11:1b:8d
Drives:    HDD Total Size: 256.1GB (66.2% used)
           ID-1: /dev/sda model: KINGSTON_SMSR150 size: 128.0GB
           ID-2: /dev/sdb model: KINGSTON_SMSR150 size: 128.0GB
Partition: ID-1: / size: 9.2G used: 7.1G (82%) fs: ext4 dev: /dev/md126p6
RAID:      Device-1: /dev/md126 - active raid: 0 components: online: sda sdb
           Device-2: /dev/md127 - inactive components: online: none spare: sda sdb
Sensors:   System Temperatures: cpu: 49.0C mobo: 41.0C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 211 Uptime: 19:15 Memory: 3572.1/7730.7MB Init: systemd
           Client: Shell (zsh) inxi: 2.2.33

mikeza · « **Reply #6 on:** February 16, 2016, 11:22:18 pm »

Would you believe how fast J River breaks if you leave logging on? Wow. Disabled logging on a whim wondering why the issue would be getting worse as the days go by and have no more serious lag during playback. ~~The GUI is still slightly laggy while refocusing as I initially described but it's definitely usable again.~~

Edit: After an hour of playback the GUI is once again entirely unresponsive to commands. Weird that it got so much better in the short-term from disabling logging. Really baffled now.

After sitting on the GUI for 10 minutes and pausing playback I can get to to be semi-responsive again. Still feels very playback dependent, left it stopped for a while and refocused without any problems. Leaving the tunes paused seems to cause problems as well.

JimH · « **Reply #7 on:** February 17, 2016, 06:36:23 am »

A log might help.

http://wiki.jriver.com/index.php/Logging

mwillems · « **Reply #8 on:** February 17, 2016, 02:43:51 pm »

Quote from: mikeza on February 16, 2016, 11:22:18 pm

Would you believe how fast J River breaks if you leave logging on? Wow. Disabled logging on a whim wondering why the issue would be getting worse as the days go by and have no more serious lag during playback. ~~The GUI is still slightly laggy while refocusing as I initially described but it's definitely usable again.~~

Edit: After an hour of playback the GUI is once again entirely unresponsive to commands. Weird that it got so much better in the short-term from disabling logging. Really baffled now.

After sitting on the GUI for 10 minutes and pausing playback I can get to to be semi-responsive again. Still feels very playback dependent, left it stopped for a while and refocused without any problems. Leaving the tunes paused seems to cause problems as well.

I also run MC on Arch with Gnome on a Haswell i7 (a quad core instead of a dual core, but otherwise we have moderately similar systems) and I don't see the issues you're describing. The behavior you're describing sounds very much like memory pressure (swapping), disk space issues, or I/O issues. Have you kept an eye on your system monitor as MC continues playback to see if there are any links (increasing memory usage, hard drive usage, i/o throughput, etc.)? Also do you have the "play from memory" option enabled?

The fact that logging exacerbates it points even more strongly to a disk space or i/o issue IMO. It looks like you have a RAID partition that's 82% full? Are MC, /tmp, and/or /var on that partition? Could MC be filling the partition with temporary files, running out of disk space and choking? Is the network involved in playback in anyway?

I'm just theorizing, as I'm not sure why we're seeing such different outcomes.

mikeza · « **Reply #9 on:** February 21, 2016, 04:56:32 pm »

Thanks for the responses guys.

The issue actually resolved itself (briefly) until now so I'm having a hard time pinning down what is causing the problem. I just discovered that while mediacenter is frozen it is using very little memory but a massive amount of CPU (constant 60%). In top, its state alternates between running and sleeping. Why does mediacenter have high CPU usage while media is paused? When media center is working without freezing, playback CPU usage is ~20%. What could it be doing while frozen?

mwillems: Yes everything for the system is on that partition, (the media files are on a separate partition) I'd be impressed if it was filling the partition but I could expand it and see if that helps. I've disabled and enabled play from memory without consequence.

JimH: I'll try to get a log that captures useful input on the behavior.

imugli · « **Reply #10 on:** February 23, 2016, 09:05:27 pm »

Hmmm... seems I'm having this issue as well. Refocussing on MC window takes quite some time to have any action actually occur... Ubuntu 15.10, Build 39 32bit.

Awesome Donkey · « **Reply #11 on:** February 23, 2016, 09:52:22 pm »

No issues here using Ubuntu 15.10 with the 64-bit build.

mikeza · « **Reply #12 on:** February 27, 2016, 05:29:04 pm »

Here is a log from ~initialization -> playback start (Ctrl-F Fireworks) -> stop -> program exit with extreme hangs during the playback. I don't really see anything that stands out but I'm not familiar with log contents.

Notes: I'm concerned this may have something to do with sleep/resume or the presence or lack thereof of my DAC during boot or JRiver start. Trying to correlate those with the problem... Hangs are not resolved by JRiver restart, but often are fixed by a full reboot of Arch.

mikeza · « **Reply #13 on:** March 03, 2016, 01:16:28 am »

Is there a reason that removal of my DAC would cause these problems?

JimH · « **Reply #14 on:** March 03, 2016, 06:43:32 am »

If it came with a driver, try uninstalling the driver.

mwillems · « **Reply #15 on:** March 03, 2016, 08:15:48 am »

I'm not a log expert, but just browsing through it looks like there might be a problem related to autoimport. Are any of your watched directories on slow/external drives or networked drives? If so, how are you mounting them? Sleep/resume on Linux can cause mischief with auto mounted volumes. Auto-import can sometimes hang JRiver for a bit on other platforms when the drive it's trying to access is non-responsive. The CPU use may be related to analyzing files or thumbnailing as part of auto-import

Can you try disabling auto-import as a diagnostic test and see if that helps? If it does turn out to be auto-import related, that would explain why it only happens at intervals seemingly unpredictably.

mikeza · « **Reply #16 on:** March 03, 2016, 09:42:20 pm »

Quote from: mwillems on March 03, 2016, 08:15:48 am

Can you try disabling auto-import as a diagnostic test and see if that helps? If it does turn out to be auto-import related, that would explain why it only happens at intervals seemingly unpredictably.

Unfortunately I've already disabled running auto-import in the background and the issue persists. It's definitely only a problem during playback, but the issue is not limited to playback on a certain device. My media is on the same drive as the primary system right now anyway.

Jim, I didn't install a specific driver for my DAC. The issue persists through reboots and before and after removal of the DAC so although I have a small feeling it seems related I'm not anywhere near certain it's the cause.

I've moved away from Gnome in hope that it would fix the problem but unfortunately it is unchanged. It's actually more visible as the all the non-updating GUI elements (e.g. all but playerbar and a select few other chunks) don't load when I change to JRiver.

JRiver becomes entirely unusable when this occurs... which is daily. I'm considering changing media applications after many years of loving use

mikeza · « **Reply #17 on:** March 16, 2016, 06:45:13 pm »

I did a completely clean reinstall of JRiver and the problem was 100% resolved for a week or so before returning. It appears to be getting worse as I run the program longer.

What can I try clearing or deleting that would build up over time?
My thoughts are:
- thumbnail caches
- library?
- logs are disabled but.. logs?

Also, my music is being stored on a FAT32 partition that doesn't support unicode yet a lot of the file names attempt to use UTF-8 characters and are broken from my transition to NTFS to FAT32. J River doesn't seem to realize that it can't use UTF-8 for renames on the partition. Possible factor?

Awesome Donkey · « **Reply #18 on:** March 16, 2016, 06:51:51 pm »

This is likely an Arch issue, I'm thinking. Have you thought about reinstalling Arch?

mikeza · « **Reply #19 on:** April 09, 2016, 05:03:17 pm »

Installing arch was a huge pain in the ass due to my unsupported FakeRAID. I guess I'd be better at it a second time but I really rather wouldn't do it

For those who care, I've resolved this issue by disabled thumbnail building on auto import. I'm 90% sure this is the source of the problem, why and how I don't really know.

mwillems · « **Reply #20 on:** April 09, 2016, 05:53:35 pm »

Quote from: mikeza on April 09, 2016, 05:03:17 pm

Installing arch was a huge pain in the ass due to my unsupported FakeRAID. I guess I'd be better at it a second time but I really rather wouldn't do it

For those who care, I've resolved this issue by disabled thumbnail building on auto import. I'm 90% sure this is the source of the problem, why and how I don't really know.

Most likely it's a bad file that's choking MC. You can import/build thumbnails in batches until you identify the problematic files.

INTERACT FORUM

Author Topic: Window refocus hangs (Read 11020 times)