•   
  • 1
  • 157
  • 158
  • 159(current)
  • 160
  • 161
  • 168
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
(2015-12-02, 19:08)popcornmix Wrote:
(2015-12-02, 17:03)afremont Wrote: I'm using videoplayer with mmal enabled and the default interlacing

Can you confirm if it is a memory leak? e.g. leave it running once it starts stuttering and see if it eventually crashes with out-of-memory reported in dmesg log.

Can you narrow down in what circumstances it occurs?
Does stopping and starting playback resolve the issue? If not does restarting kodi (without rebooting) resolve the issue ("systemctl restart kodi").
Does it occur with recordings?
Does it occur with omxplayer enabled?
Does it occur with deinterlace disabled?
Does it occur with sync playback to display enabled/disabled?
Does it occur with passthrough enabled/disabled?
Is it a new issue? Can you identify the build that first introduced it?

Stopping and restarting works for a while.
Live TV is the only thing that gets as bad as I've seen, but my recordings are mostly 30 minutes each. Usually this takes an hour or two of live TV to really get noticeable.
Using OMXPlayer works quite well with only fraction of the CPU usage that videoplayer uses. OMXPlayer usually uses on the order of 12% whereas videoplayer uses around 50% in the main thread.
I don't know if disabling deinterlacing does anything. I will try to find out. I do know that I had previously "locked" in MMAL Advanced for Deinterlace Method, but after renaming the .kodi directory, that was back to Auto select for the method. I always have Deinterlace Video set to Auto.
Sync playback to display is enabled
Pass through is currently disabled since I was using resample audio, now I have it set to adjust pll.

This has been ongoing for a while. I can't begin to tell you the version that first started having this particular problem yet. I did identify the exact version that had frame dropping and audio sync issues when the GUI was up, but you seemed upset and just patched things to drop every other frame when the gui is up even though that particular problem didn't appear until a specific version. After that, I figured you really didn't want to be hearing from me about it anymore so I went back to using OMXPlayer. 3D support seems to be what it's all about anyway and I personally don't need it for my setup. What I need is something reliable that my wife can live with. Smile

I'm sorry that I can't be more specific. I'm not able to do daily updates anymore because of life things. I figured that since other people weren't complaining that I was the only one due to some kind of local problem or unique situation. I use MPEG2 for TV because I have two HDHomerun tuners. I use Mythbuntu for the backend and the Raspberry Pi for the frontend.

I'm going to switch my frontend boxes. I have a Pi in the bedroom running a released version of OpenELEC and I'm going to move it to the living room. I will put the nightly box in there so I can try various things to try and figure out the problem. I can't just leave things running until they blow completely up in the living room because my wife uses it. I'm not promising anything, but I will TRY to go back and find the first version that started this particular problem. The box in the bedroom is rarely used anyway.

I'm concerned that maybe all this is unique to me, that's why I asked about renaming the folder before shouting out loud about my problems. I've been noticing that when running htop on a couple of different linux boxes I have, that sometimes it just stops updating for a few seconds (up to 10). If other network traffic is having this kind of problem, then I can see why Kodi is having issues with buffering, freezing and keeping things smooth and synchronized. I'm in the process now of swapping out some switches to see if it makes any difference. I do know that when htop stops updating on one connection, it continues to update on others. This tells me that I might be having a switch issue. I've had some nasty power hits in the last few months, so anything is possible. When I'm the only one noticing something, I'm hesitant to say anything on the forum.

Before you go on a wild goose chase, let me do some more testing and see if I can find anything that I can reproduce on demand. I also want to figure out this htop freezing stuff. I'm going to buy a managed switch that I can do port mirroring with so that I can run wireshark and see if I can see a freeze in the stream from the TV tuner to the Myth box or from there to the Pi.
Experience: It's what you get when you were expecting something else.
(2015-12-03, 13:44)Milhouse Wrote: I've replaced the last build with #1202b, which has functioning libcec.

Thanks - working for me too.
(2015-12-03, 17:52)afremont Wrote:
(2015-12-02, 19:08)popcornmix Wrote:
(2015-12-02, 17:03)afremont Wrote: I'm using videoplayer with mmal enabled and the default interlacing

Can you confirm if it is a memory leak? e.g. leave it running once it starts stuttering and see if it eventually crashes with out-of-memory reported in dmesg log.

Can you narrow down in what circumstances it occurs?
Does stopping and starting playback resolve the issue? If not does restarting kodi (without rebooting) resolve the issue ("systemctl restart kodi").
Does it occur with recordings?
Does it occur with omxplayer enabled?
Does it occur with deinterlace disabled?
Does it occur with sync playback to display enabled/disabled?
Does it occur with passthrough enabled/disabled?
Is it a new issue? Can you identify the build that first introduced it?

Stopping and restarting works for a while.
Live TV is the only thing that gets as bad as I've seen, but my recordings are mostly 30 minutes each. Usually this takes an hour or two of live TV to really get noticeable.
Using OMXPlayer works quite well with only fraction of the CPU usage that videoplayer uses. OMXPlayer usually uses on the order of 12% whereas videoplayer uses around 50% in the main thread.
I don't know if disabling deinterlacing does anything. I will try to find out. I do know that I had previously "locked" in MMAL Advanced for Deinterlace Method, but after renaming the .kodi directory, that was back to Auto select for the method. I always have Deinterlace Video set to Auto.
Sync playback to display is enabled
Pass through is currently disabled since I was using resample audio, now I have it set to adjust pll.

This has been ongoing for a while. I can't begin to tell you the version that first started having this particular problem yet. I did identify the exact version that had frame dropping and audio sync issues when the GUI was up, but you seemed upset and just patched things to drop every other frame when the gui is up even though that particular problem didn't appear until a specific version. After that, I figured you really didn't want to be hearing from me about it anymore so I went back to using OMXPlayer. 3D support seems to be what it's all about anyway and I personally don't need it for my setup. What I need is something reliable that my wife can live with. Smile

I'm sorry that I can't be more specific. I'm not able to do daily updates anymore because of life things. I figured that since other people weren't complaining that I was the only one due to some kind of local problem or unique situation. I use MPEG2 for TV because I have two HDHomerun tuners. I use Mythbuntu for the backend and the Raspberry Pi for the frontend.

I'm going to switch my frontend boxes. I have a Pi in the bedroom running a released version of OpenELEC and I'm going to move it to the living room. I will put the nightly box in there so I can try various things to try and figure out the problem. I can't just leave things running until they blow completely up in the living room because my wife uses it. I'm not promising anything, but I will TRY to go back and find the first version that started this particular problem. The box in the bedroom is rarely used anyway.

I'm concerned that maybe all this is unique to me, that's why I asked about renaming the folder before shouting out loud about my problems. I've been noticing that when running htop on a couple of different linux boxes I have, that sometimes it just stops updating for a few seconds (up to 10). If other network traffic is having this kind of problem, then I can see why Kodi is having issues with buffering, freezing and keeping things smooth and synchronized. I'm in the process now of swapping out some switches to see if it makes any difference. I do know that when htop stops updating on one connection, it continues to update on others. This tells me that I might be having a switch issue. I've had some nasty power hits in the last few months, so anything is possible. When I'm the only one noticing something, I'm hesitant to say anything on the forum.

Before you go on a wild goose chase, let me do some more testing and see if I can find anything that I can reproduce on demand. I also want to figure out this htop freezing stuff. I'm going to buy a managed switch that I can do port mirroring with so that I can run wireshark and see if I can see a freeze in the stream from the TV tuner to the Myth box or from there to the Pi.

I have an almost identical setup, 2 HD Homerun Primes, Charter as my cable provider and mpeg2 streams (I do not have the transcoding HD Homerun devices), MythTV (running on Fedora 20 though) and 2 RPi2 frontends. One of my RPi2 boxes is hooked to an old square CRT TV using the composite connector and the other is hooked up to a 1080p LCD with HDMI. I have both adjust display refresh rate and sync playback to display enabled, for the latter I am using the PLL option. I only have MMAL enabled (OMXPlayer is disabled). I've also set advanced deinterlacing as the default for all video and it is working quite well for me.

I'm not seeing any of the issues you've mentioned, but I do update almost every day. On the weekends I'll have liveTV going for several hours (usually on CNN HD or Cartoon Network HD) and I've not seen stuttering or any out-of-memory issues. I do change the GPU memory settings in config.txt with gpu_mem_1024=320 since the RPi2 has 1gb of memory.
(2015-12-02, 23:55)Milhouse Wrote: [*][input] Add some logging for input device (54c1f25c)

@jackiass - can you update to latest version (which will still have the multitouch issue) and post a debug log?
I've added some logging that shows all the features your keyboard reports. I suspect it is reporting something multitouch related which causes the conflict.
@afremont: You can use "bcmstat.sh ZAD" to monitor memory allocations, and if you're lucky more quickly identify when memory is leaking.

The values in the "Delta" column represent the amount of memory allocated during the last interval period - generally speaking the values in this column should be a random mix of allocations (-, red) and frees (+, green) - an excessive number of allocations is not a good sign, and may indicate leakage.

The values in the "Accum" (accumulated) column represent the total amount of memory allocated (or freed) since bcmstat.sh started. If this number is increasingly negative then it would suggest memory is being steadily consumed, without ever being freed. In normal circumstances this figure should remain close to zero and/or fairly static, with only occasional large allocations - eventually freed - as you navigate the Kodi GUI, start/stop videos etc. Starting background applications/services will also consume memory and skew the Accum column, but you'll need to manually account for this.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-12-02, 17:42)doveman2 Wrote: This seems to be a consistent issue with #1128. Almost every other time I try to play a file this happens, then when it eventually times out and I try again it plays fine. Also, when scanning for updates it got stuck on 'Preparing to scan' for ages. I'll try #1201 and see if it's fixed.

Seems to be fine with #1201 thanks.
Thanks zaphod24, I'm wondering if I'm having trouble with that Pi. I'm going to switch some things around and see what happens. I can't use adjust refresh rate because it causes black screens for a few seconds while my AVR and projector adapt to it. In the bedroom, I'll be able to use that option and see if it makes any difference.

I turned off IPV6 in my Myth box and it appears to be off in the pi by default though the proc system shows it not disabled. I think that has helped to some extent. I'm going to just switch SD cards in the two pi boxes to make sure that the problems actually follow the OS and not the hardware.

What benefit do you suppose you get with gpu_mem_1024=320?

I'm also going to order a couple of managed switches to see if I can nail down this network freezing (may just be the result of a dropped packet on a TCP connection for all I know). At any rate, I'm suspicious that I do have a local problem of some kind.

I switched SD cards, so we'll see what happens now.
Experience: It's what you get when you were expecting something else.
(2015-12-03, 19:27)afremont Wrote: Thanks zaphod24, I'm wondering if I'm having trouble with that Pi. I'm going to switch some things around and see what happens. I can't use adjust refresh rate because it causes black screens for a few seconds while my AVR and projector adapt to it. In the bedroom, I'll be able to use that option and see if it makes any difference.

I turned off IPV6 in my Myth box and it appears to be off in the pi by default though the proc system shows it not disabled. I think that has helped to some extent. I'm going to just switch SD cards in the two pi boxes to make sure that the problems actually follow the OS and not the hardware.

What benefit do you suppose you get with gpu_mem_1024=320?

I'm also going to order a couple of managed switches to see if I can nail down this network freezing (may just be the result of a dropped packet on a TCP connection for all I know). At any rate, I'm suspicious that I do have a local problem of some kind.

I switched SD cards, so we'll see what happens now.

At one point when the 3D GPU (I think that's what they used) advanced deinterlacing first came along, I just decided to give the GPU a little more memory to work with since it seemed (maybe a placebo) to help with scrolling text stuttering. Since that still leaves 688mb for the ARM chip and OS I felt it was ok. I've just left mine that way.
(2015-12-01, 14:09)popcornmix Wrote:
(2015-12-01, 12:29)Edddsch Wrote: I still having problems when switching back to 2D mode on my Phillips TV

here the Debug-Logs:
B1109: http://pastebin.com/vrYNmRfh
B1110: http://pastebin.com/vNAYwv7p

Can you post *complete* debug log from latest Milhouse build?

Debug Log #1202b: http://xbmclogs.com/piicebfbw
Hello again,

DVD Menue is also broken with this #1202 build.
PhillCollins Disk1 Finally concert in Paris is hanging with 100% Buffering on Kapitel 01/16 (notification on screen)
Milhouse know this Disk, because this Disk has much more Kapitels like others DVD. We've spoken some month or one year ago about. ;-)
i was in due course a beginner in OpenElec, awesome :-)

This Disks are not easy to play, i know ....but on standart hardware DVDplayer all works.....like in build 1001. ;-)

With iso.files i dont have problems (why?)....zappa plays zappa work fine with this build, also iso.file no2 from 2 disks.(not tested all my iso)
New OpenELEC Jarvis build #1203: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.3.0 #1 Thu Dec 3 21:03:01 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Nov 30 2015 20:58:50
Copyright (c) 2012 Broadcom
version 411fa8fd4bbe6a0a4b0c50f09330ce84c1d70b3d (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20151203210211-#1203-gc5875ae [Build #1203]

# vcdbg log msg 2>&1 | grep DTOK
001694.355: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (c5875ae6, changelog) and tip of XBMC master (f4196378, changelog) with the following modifications: Build Highlights:
  1. Re-add PR:7030 (CNetwork - implement IPv6) now issues are fixed
Build Details:
  1. XBMC:
    • fix strings after #8180 (PR:8470, 1 commit, 1 file changed)
    • [fix/cleanup] Fix some cppcheck issues. (PR:8466, 7 commits, 7 files changed)
    • android: fix event source evaluation (no touch events on stylus devices) (PR:8472, 1 commit, 1 file changed)
    • Fix DPMS detection for X11 without GLX (PR:8467, 1 commit, 1 file changed)
    • [GUI] remove "Add source" from MyPrograms section (PR:8468, 1 commit, 1 file changed)
    • [lang] updated language files from Transifex for Skin Confluence (f4196378)
  2. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [pkg] PR:7030: CNetwork - implement IPv6
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Hi guys

i have a problem and i'm not able to fix it by myself.
I hope i am in the right topic and you can help me.

First of all my Hardware:
Raspberry Pi 2 Model B
Pioneer VSX-923 (AVR)
Acer H6517ST (Projector)
LG 47LM670S (TV)
And a PC ^^

Problem:

I want to use the Raspberry to play 3D Bluray ISO's.
The Options in Raspberry's setup (full frame 3D and Use Full HD HDMI Modes for 3D) are enabled.
If i start an ISO file it starts in SBS mode
If i do this after a hardreset it starts in Framepacking mode but... only one time
when i stop the movie and resume/restart it, it will be playing in SBS mode
restart/softreset have no effect
Every Framepacked content now is playing in SBS mode

Now it will be a little curious...
when i pull out a HDMI Cable (no matter if Raspberry's or the one from the projector) and put it back in the Raspberry plays in FP mode.

playing FP content from PC via PowerDVD is no Problem
playing FP content from Raspberry is no problem to on the TV
With TV and Projector Both powered on playing FP Content from Raspberry the TV switches automatically in 3D mode and the Beamer shows me a SBS Picture (see pic)

[Image: z343brbi.jpg]

My way to try to fix it:

Restarting Raspberry
Reinstalling Openelec
Changing HDMI Cables
Changing HDMI OUT on AVR
Connecting Raspberry directly to the Projector
Trying another ISO

all that wont help

The only Way to get Framepacked Video is pull out and put back in The HDMI Cable.
Or using PowerDVD on PC (Power consumption Angel)

I hope somebody can help me

If this is the wrong forum feel free to move this post

For more information just ask

Thanks for your time to read my story

knonzl
I put the flash card into the Pi in the bedroom and put on a 720P TV channel. After a couple of hours I checked on it. It's moving along oddly and CPU usage is through the roof again. Looks like the problem is not hardware related unless it's the flash card itself. I left all the setting the same as they were. There is nothing in the log for the last couple of hours. dmesg shows nothing. There's no audio though, and that's a little different. I'm going to test it again but keep a closer eye on it. I have a keyboard connected and bringing up the OSD using 'O' shows a very large number of skipped frames increasing by 10 to 15 per second, but very few dropped frames. CPU usage from 3 of the cores shows a total of about 50% and the final core shows a solid 100% utilization. I have the appropriate MPEG2 licenses installed.

Sync Playback to display is on
Adjust refresh rate is off
Adjust PLL is on for audio sync

Here is a screenshot of the OSD when the problem is occurring:
https://www.dropbox.com/s/7lnhl0oogkkvaf...2.png?dl=0

Here is a screenshot of the OSD immediately after stopping live TV playback and restarting it:
https://www.dropbox.com/s/8lguefxvzk4h2f...3.png?dl=0

Sound immediately returned along with smooth playback.


This TV uses a different network switch than the living room does. It does share the same upstream switch the HDHomerun goes through though. The freezing of htop doesn't involve either of those two switches though since I'm plugged into the switch in the living room along with the Pi and the MythTV box. This is really perplexing and I've been messing with networks for more than 20 years, Linux too. At first I though it was Putty and WIndows 10, but Windows 7 did it as well. I'm still going to try another client instead of Putty to make sure it's not that. Right now, I don't have any reason to blame anything but Putty when it comes to the SSH sessions freezing for a few seconds. I feel that 10 second freezes on live TV or recordings would result in larger issues than I see. That said, I don't understand why I'm the only one having these issues. It can't be my Raspberry Pi since I'm using a different one now and having the same issue. zaphod24 has adjust refresh rate on so I'm going to do a test with that on to see if the problem still occurs.
Experience: It's what you get when you were expecting something else.
Update, running another test after a clean boot using the same settings. Live TV looked good for about 2 hours, then it started skipping frames. The audio stayed in sync, but the picture was really jerky with the skipped frames. CPU usage remained normal for a few minutes, then climbed through the roof. So it would appear that the frame skipping doesn't result from high CPU usage, but leads to it eventually. The sound continued to play okay. I'm going to let it play for a while longer and see if the sound stops like it did earlier. I wasn't watching it as closely earlier. After a few more minutes (10 or 15), the audio began to come and go and was out of sync.

I checked the CPU frequency and it was 900MHz (I thought maybe it might be throttling back to 600MHz for some reason and causing this, but no such luck). No messages in the log file for over 2 hours and nothing in the dmesg output. I don't know what else to check. In htop, the VIRT memory stayed pretty much at 564M, but the RES increased from 101M to 103M after the problem appeared. There are basically four PIDs running and the lowest numbered PID is the one consuming all the CPU. All of them are /usr/lib/kodi/kodi.bin.

I stopped the live TV playback and restarted it on the same channel (720p). htop showed pretty much normal values, though the VIRT had dropped to 560M and RES increased to 121M. Should the RES value increase like that?

EDIT: Stopping playback again and restarting the same channel lowered VIRT to 542M and RES went down to 105M. So it doesn't appear that start/stop are leading to some type of leak as far as I can tell from looking at htop output.

On a side note, I used the Bitvise SSH client (tunnelier) to access the Pi and still had the occasional "freeze" when running htop. Whatever is causing that doesn't seem to be related to the client program. I don't notice any such "freezing" when doing speed tests, file copies etc across the network. Everything seems to be okay, and when htop stops updating for a few seconds, other things continue to work just fine.
Experience: It's what you get when you were expecting something else.
(2015-12-01, 03:26)doveman2 Wrote: Bit more information from my brother. He says the message he sees is "'successfully removed device", so it doesn't actually sound like Tvheadend is being uninstalled. It may be just a coincidence that he sees this and finds TVh isn't working until he re-installs it and maybe he's running into the same problem as I have with the tuner randomly disappearing, at least as far as TVh is concerned. Any ideas what that message might be about though? I searched the log and the only mention of 'removed' I found was near the end where it says 'UDev: Removed (null)'.

I'll try updating him to #1128, the same as I'm on now, to see if that improves things for him anyway.

Haven't had a chance to update my brother's RPi yet but he's sent me another log from #1015.

I see at 19:40:06 the "NOTICE: UDev: Removed (null)" message and TVheadend seems to have been working OK just before that and updating the EPG and in fact immediately after but at 19:47:36 it seems to have failed with "AddOnLog: Tvheadend HTSP Client: pvr.hts - Bad subscription status: No input detected" messages after he tried to start a channel.

http://www.xbmclogs.com/pxebe3gcg

I'll hopefully get him updated to #1201 today, so if you don't know what might be happening don't worry, I just thought I might as well post it before I update him. I've just noticed he hasn't got max_usb_current=1 set, which I thought I'd done for him, so I'll try adding that as well to see if it helps.
  •   
  • 1
  • 157
  • 158
  • 159(current)
  • 160
  • 161
  • 168
  •   
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)510