• 1
  • 80
  • 81
  • 82(current)
  • 83
  • 84
  • 111
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1
(2015-03-19, 14:42)zaphod24 Wrote: Thanks for the 0319x debug build. Of course it has been perfect and not crashed, so I guess the issue with the EPG is fixed Smile

So far so good on this end too. I haven't played with it much, but it seems to be working ok. Looking forward to the real 319 build. I just put it through a few hoops and it's looks pretty good. Recordings seem to start faster than before.

EDIT: I thought I should add that it's been running for hours without issue. I'll put on a recording and let it run while I go to lunch.
Experience: It's what you get when you were expecting something else.
(2015-03-19, 04:53)Milhouse Wrote: @zaphod24/@afremont: There's a debug-enabled RPi2 build with menakite's patch here: #0319x (not bothering with an RPi build as you're both RPi2 users) - please upload your crash logs if it continues to crash, thanks.

Edit: UK, have always preferred working late... although probably calling it quits for tonight!

I've tested the #0318 for RPi, but the same problem, crash after epg-load.
Is it possibly to get a #0319-alpha-testbuild for rpi ?
That's great, thanks both.
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-03-19, 20:28)Heiko123 Wrote: I've tested the #0318 for RPi, but the same problem, crash after epg-load.
Is it possibly to get a #0319-alpha-testbuild for rpi ?

There's a debug build, #0319x, or wait for tonight's regular build.
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.
New OpenELEC Isengard build #0319: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.19.2 #1 Thu Mar 19 21:02:22 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Mar 16 2015 19:34:31
Copyright (c) 2012 Broadcom
version 51ab816b505d1b745130562908d866915c836056 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150319210132-#0319-g788bd7a [Build #0319]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (788bd7a7, changelog) and tip of XBMC master (79107ec6, changelog) with the following modifications: Build Highlights:
  1. New 3.19.2 kernel
  2. Fix for EPG database crash
  3. Include new addon audio decoders: modplug, nosefart, sidplay, stsound, snesapu, timidity and vgmstream
Build Details:
  1. OpenELEC:
    • Update package.mk (PR:4021, 1 commit, 1 file changed)
    • linux: remove upstream patches (PR:4023, 1 commit, 3 files changed)
    • libva-intel-driver: Fix Advanced deinterlacing on IVB SNB BYT (PR:4022, 1 commit, 1 file changed)
    • linux: update to linux-3.19.2 (a8fde712)
    • libXfont: update to libXfont-1.5.1 (39474519)
    • vdr-addon: bump (4.3.11) (788bd7a7)
  2. XBMC:
    • [art] container.art() fixes (PR:6761, 2 commits, 2 files changed)
    • [fonts] fix font mask after 4e542f7 (PR:6760, 1 commit, 2 files changed)
    • Added some support for a titlebar-less functionality on OSX, the window ... (PR:6762, 1 commit, 1 file changed)
    • binary addons: add audiodecoders (PR:6600, 3 commits, 18 files changed)
    • renderer: eat video frames properly if there is no consumer - fix crash ... (PR:6731, 1 commit, 1 file changed)
    • [lang] Add proper support for custom languages (PR:6736, 2 commits, 4 files changed)
    • [music/videolibrary] adjust sort order labels (PR:6740, 2 commits, 2 files changed)
    • [pvr] fix type of CPVRChannelGroup's m_iPosition (PR:6764, 1 commit, 1 file changed)
    • fix TV language detection with HDMI-CEC (PR:6766, 1 commit, 1 file changed)
    • [epg] fix use of new epg database column iYear (PR:6763, 1 commit, 1 file changed)
    • Addon manager improvements (PR:5862, 5 commits, 7 files changed)
  3. pvr.demo:
    • Handle channel group positions (PR:4, 2 commits, 4 files changed)
    • bump addon version to 1.10.3 (PR:5, 1 commit, 1 file changed)
  4. kernel 3.19.y:
    • New commits in this build:
      • bcm2708: Make ioctl logging quieter (c71cb291)
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.
Thanks, all is fine. I dont get a epg crash. Smile
Just a heads up:
After about an hour, I'm noticing the audio video sync getting off enough that my wife even notices. I'm fairly sure we get the same thing with OE 5.0.6 too. This is with TV recordings (MPEG2). If I completely stop and resume it, it's ok again. She pauses and skips back and forth a lot, but I don't know if that has anything to do with it. Tonight, I'll check if it shows when pressing O and looking at the codec info. I use OMXPlayer. Audio Offset is most definitely set to 0.000 this time, for sure. Seems to be generating a lot of these during playback:
Code:
04:50:03 72266.812500 T:1583346752 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
04:50:03 72266.820312 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:50:04 72266.914062 T:1583346752 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
04:50:04 72266.921875 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:51:25 72348.000000 T:1968910336 WARNING: Previous line repeats 2484 times.
04:51:25 72348.000000 T:1968910336  NOTICE: CDVDPlayer::CloseFile()
04:51:25 72348.000000 T:1968910336  NOTICE: DVDPlayer: waiting for threads to exit

The snippet is from letting it play for a minute and then stopping the recording playback. Looks like it is continually generating the "didn't consume full packet" while playing back, then skipping cause it to spit out teh CRenderManager::WaitForBuffer line followed by the packet consumption errors. These are related to the subtitle stream being opened (stream 0). I believe that OE 5.0.6 simply refuses to open the stream at all. There's something fishy about WMC recorded TV subtitle streams. Maybe this is problem with OMXPlayer? I'll try MMAL, but in the past it just didn't like the recorded TV streams, might be from the TV signal quality. Maybe all of it is related to signal quality.

Here's the beginning of the playback messages:
Code:
04:43:26 71869.726562 T:1968910336  NOTICE: DVDPlayer: Opening: smb://USERNAME:PASSWORD@I7-PC/Users/Public/Recorded TV/Thriller_KUBEDT4_2015_03_19_03_00_01.wtv
04:43:26 71869.726562 T:1968910336 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
04:43:26 71869.726562 T:1593832512  NOTICE: Thread DVDPlayer start, auto delete: false
04:43:26 71869.734375 T:1593832512  NOTICE: Creating InputStream
04:43:27 71869.929688 T:1593832512  NOTICE: Creating Demuxer
04:43:27 71870.335938 T:1593832512  NOTICE: Opening stream: 1 source: 256
04:43:27 71870.367188 T:1593832512  NOTICE: Creating video thread
04:43:27 71870.367188 T:1583346752  NOTICE: Thread OMXPlayerVideo start, auto delete: false
04:43:27 71870.367188 T:1593832512  NOTICE: Opening stream: 0 source: 256
04:43:27 71870.367188 T:1593832512  NOTICE: Creating audio thread
04:43:27 71870.367188 T:1792013376  NOTICE: Thread OMXPlayerAudio start, auto delete: false
04:43:27 71870.367188 T:1593832512  NOTICE: Opening stream: 2 source: 256
04:43:27 71870.375000 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:43:27 71870.445312 T:1593832512 WARNING: Previous line repeats 155 times.
04:43:27 71870.445312 T:1593832512  NOTICE: OMXClock using audio as reference
04:43:27 71870.453125 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:43:27 71870.523438 T:1583346752 WARNING: Previous line repeats 43 times.
04:43:27 71870.523438 T:1583346752  NOTICE: Display resolution DESKTOP : 1920x1080 (1920x1080) @ 60.00 - Full Screen (16)
04:43:27 71870.523438 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:43:34 71877.734375 T:1583346752 WARNING: Previous line repeats 408 times.
04:43:34 71877.734375 T:1583346752 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
04:43:34 71877.765625 T:1593832512 WARNING: Decode - avcodec_decode_subtitle didn't consume the full packet
04:43:35 71877.835938 T:1583346752 WARNING: Previous line repeats 54 times.
04:43:35 71877.835938 T:1583346752 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

FYI, it's been up since around 9:00am yesterday with no crashes.
Experience: It's what you get when you were expecting something else.
Maybe the OMXPlayer audio video sync issue is related to this:
http://stackoverflow.com/questions/21443...ut-of-sync
http://stackoverflow.com/questions/21399...0#21422270

What are the command line arguments to ffmpeg and OMXPlayer?
Experience: It's what you get when you were expecting something else.
(2015-03-20, 12:05)afremont Wrote: Just a heads up:
After about an hour, I'm noticing the audio video sync getting off enough that my wife even notices. I'm fairly sure we get the same thing with OE 5.0.6 too. This is with TV recordings (MPEG2). If I completely stop and resume it, it's ok again.

I would be useful to confirm that nightly and 5.0.6 behave the same (I suspect they will).
Also use to describe the behaviour with omxplayer acceleration disabled.

Try to identify exactly what causes the issue. Do you ever see audio/video glitches (e.g. caused by a bad signal) in these files? Does out-of-sync typically follow these?
Does pause/unpause or seeking make it better/worse?

Use the OSD audio settings to adjust sync to correct it, and report how much correction is required

If you can provide a sample file with clear instructions of how to see the problem (e.g. play and it starts in sync, but it is +300ms out of sync at 1m30, or seek forwards twice and it will be -200ms out of sync). Upload file (e.g. to dropbox or google drive) and I'll look into it.
I can confirm that Live mpeg2 TV exhibits the same audio video sync problem in Openelec 5.0.6.

I left the World cup cricket playing all day and when a News service started, minor audio / video lip sync problems were noticable.
This would have been after 5 or 6 hours of continuous play. No user intervention with Kodi all that time.

OMXPlayer Acceleration enabled
No Audio or Video glitches
Signal Quality good.

Will try the ms correction next time I see it.

I can say this much with reasonable confidence. Completely stopping playback and resuming it seems to fix it. It seems to creep in over time. I'm playing the recording that did it last night. I'll let it go for a while and report back. Right now, the codec report shows ad:3.13x and a/v:-4.2xx. The a/v numbers shuffle around by + or - 100mS and the ad numbers by about + or - 10mS. The video stream shows a vq of 54% + or - 1% and the dc:omx-mpeg2,Mb/s:1.75 to 2.20. That seems like a fairly low quality stream, but that's what they transmit on that sub channel. aq stays pretty much locked at 99% Kb/s:187 to 188.

I have verified that the codec is enabled and OMXPlayer is hardware enabled during this test.

I played the video completely through without skipping around, just pausing a couple of times so that it didn't end before I could check the sync near the end of video. It remained reasonably close. This was the same video my wife played last night that got at least 500mS out of sync.

I'm now going to try it with a bunch of skipping around. Here is a screen shot with the codec info showing:
https://www.dropbox.com/s/6x53oauc2todpu...0.png?dl=0
Does that look reasonable for a Pi2?

OT: I'm not sure that I really like (trust) Dropbox yet. It seems kind of intrusive and heavy handed on resources. I'll reserve judgment until I can check some things. 48 threads and 13 IP connections without even having their "folder" open from their process that runs all the time. Sad And I thought Google was suspicious. EDIT: There, all cleaned up now. No more junk running on my pc.
Experience: It's what you get when you were expecting something else.
I can't duplicate the problem. I tried skipping back and forth, pausing and skipping while paused. Nothing seems to put it as far off as it got last night. If I can find anything that will consistently duplicate the problem, I'll bring it up again. I can say that it's almost always a tiny amount off. Just perceptible to me. It seems to move back and forth just a little, going in and out of sync by maybe 100mS or probably less. I suspect most people can't see it, but my eyes resolve many images per second compared to normal people. I can always see the rainbows artifacts in DLP technology. It took me weeks to "learn" to ignore it on our projector. Dimming the image helps. It's an Optoma HD25e I'm positive that the receiver and projector aren't to blame since I don't see AV sync issues on any other programming.
Experience: It's what you get when you were expecting something else.
I have a similar dilemma. Kodi is connect to MythTV and my TV tuner is an HD Homerun Prime with Charter as my cable provider, all content is MPEG2. There are a small number of local channels that have HD on the main channel and then SD on several sub-channels.An example SD channel is MeTV which shows old programs like Andy Griffith, I Love Lucy and Star Trek TOS.

What I've noticed is that with OMXPlayer disabled, those channels have a lot of stutter. This seems very strange because all of the HD content is spot-on with OMXPlayer disabled and you'd think HD content would be much more demanding and prone to issues. Instead it is SD that has a problem.

If I enable OMXPlayer then both the HD and the SD channels look great. Unfortunately OMXPlayer also crashes sometimes with errors like this in the logs:

COMXAudioCodecOMX::GetData Unexpected change of size (12288->36864)

It would not surprise me if the MPEG2 streams from Charter have errors in them from time to time due to signal interference. OMXPlayer appears to be much more sensitive to those issues and crashes. Perhaps that is why it is no longer enabled by default in these builds?

Has anyone else seen those issues? If DVDPlayer was somehow corrected to work well with the SD content, all would be well.
(2015-03-20, 16:29)zaphod24 Wrote: What I've noticed is that with OMXPlayer disabled, those channels have a lot of stutter. This seems very strange because all of the HD content is spot-on with OMXPlayer disabled and you'd think HD content would be much more demanding and prone to issues. Instead it is SD that has a problem.
The double rate deinterlacers tend to stress dvdplayer more than omxplayer. Try disabling deinterlace, or using the "half" versions if you have stutters with dvdplayer.
Provide a sample file with stutters and I'll look into it.

Quote:If I enable OMXPlayer then both the HD and the SD channels look great. Unfortunately OMXPlayer also crashes sometimes with errors like this in the logs:

COMXAudioCodecOMX::GetData Unexpected change of size (12288->36864)
Seems the audio codec is changing frame size. It's easy to solve, but I need a debug enabled log (or a sample file).

Quote:Has anyone else seen those issues? If DVDPlayer was somehow corrected to work well with the SD content, all would be well.
Get me a sample file that plays badly with dvdplayer...
I had a lot of that stuttering, then speed variations as it resynced before, so I just made a practice of not using DVDPlayer. I'm trying DVDPlayer right now and it looks pretty decent so far. Watching MeTV as well with it's horrible bitrate for video. Here is a screenshot with codec info showing:
https://www.dropbox.com/s/fr42j7tpm5h3gn...1.png?dl=0

Looks like it skips a frame about every 10 (maybe 9.9ish) seconds. The drop:1 and pc:1 are from the beginning. As long as DVDPlayer can keep up the good work, I'm satisfied to use it instead of OMXPlayer. I'll have to give it some time and see how it goes. It seems to maintain better A/V sync than OMXPlayer at all times. I don't notice the sliding around. It might be off by a tiny amount, but it's completely acceptable.

I see the codec info seems to show the a/v going from 0 to -0.040 at the max. It takes about 1 second for a cycle of that to happen. It's updating so fast that's it's really hard to tell. I'd have to make a movie of the screen to actually see what it's doing. At any rate, it looks pretty good. I'll try sticking with DVDPlayer instead. Skipping a frame every 10 seconds isn't noticeable. Is the frame skip due to syncing to the refresh rate of the display (projector Optoma HD25e)? As in a phase type mismatch? I ask because the skip seems to occur at precise intervals.
Experience: It's what you get when you were expecting something else.
  • 1
  • 80
  • 81
  • 82(current)
  • 83
  • 84
  • 111

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 112