More > JRiver Media Center 21 for Linux
Window refocus hangs
mikeza:
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: ---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
--- End code ---
mikeza:
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:
A log might help.
http://wiki.jriver.com/index.php/Logging
mwillems:
--- 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.
--- End quote ---
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:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version