•   
  • 1
  • 128
  • 129
  • 130(current)
  • 131
  • 132
  • 156
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-11-03, 19:11)kieranc Wrote: So, the Hifiberry dev has responded, saying he's tested a digi on 3.17 under raspbian and that it worked correctly. I've just tried the 1102 build and it's as before, but I'm using a DAC+ rather than the digi - I believe they're the same chips but could be relevant.

OpenELEC 5.0 Beta 1 with a 3.17.2 kernel is now officially released.

You could test this Beta release with your Hifiberry and confirm to the Hifiberry developers whether it works or not with your hardware. I've had a quick read of your discussion thread over at Hifiberry, but let me know if they come back with any suggestions or ideas.
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.
(2014-11-05, 17:51)gendo Wrote:
(2014-11-05, 17:34)popcornmix Wrote:
(2014-11-05, 16:58)gendo Wrote: In my case with the build of the 18th video and audio resume in sync after glitch. with the current build e.g. todays' video and audio freeze after glitch and i have to stop and restart channel to view. other wise if i wait a lot of time (minutes) video and audio resume but totally out of sync.. I have the same result i.e. video freezes on current windows builds....

Okay, looks like I need to dump the packets a bit earlier. I've modified the commit, so if you repeat what you did in the next build I'll hopefully see the same effect you see.

Sure. will do first thing tomorrow morning. Thanks for your time.
here are new samples

https://dl.dropboxusercontent.com/u/5174353/S1.rar
https://dl.dropboxusercontent.com/u/5174353/S2.rar
Can confirm - with latest official beta release ( 3.17 kernel ) hauppauge remote no longer responds.
Anything I can do?
Can I raise a ticket for this- if so how do I do that?

Thanks

Pootler
If it doesn't work with the OE5 Beta1 build you should probably open an issue ticket on the OE github, perhaps someone there can look into it. Do provide links to logs, lsusb, dmesg output etc.
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 Helix build: #1106
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.17.2 #1 PREEMPT Thu Nov 6 21:04:28 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Nov  6 2014 16:37:12
Copyright (c) 2012 Broadcom
version 87c43f45f38d2ba744181e2caa5274798a3c692d (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141106210318-r19552-g9d253c1 [Build #1106]

Based on tip of OpenELEC master (9d253c15, changelog) and tip of XBMC master (1eea2297, changelog) with the following modifications:
  • Includes newclock4 patches
  • Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
  • Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.17.y
  • Excludes the OpenELEC xbmc-001-newclock4 patch in favour of sourcing these and possibly more recent patches directly from newclock4 branch
  • Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  • Disabled "Total Duration" in Confluence (see build #0221 for details)
  • Adapted service.openelec.settings to take advantage of PR:5217 [patch details]
  • Includes latest libnfs master (4a58e614)
  • Includes latest libcec master (260df18a)
  • Includes latest xbmc-pvr-addons master (067befe6)
  • Includes latest xbmc-addon-xvdr master (2bf2563c)
  • Includes CONFIG_COREDUMP=y to allow creation of coredumps (see here)
  • Includes additional ffmpeg codecs/muxers enabled for testing/benchmarking purposes (see patch)
  • Includes commits from libcec-2.2.0 (popcornmix)
  • Includes PR:373: Release v1.9.25 (kodi-pvr-addons)
  • Includes PR:374: [pvr.hts] Backported GetPlayingTime from pvr.tvh. (kodi-pvr-addons)
  • Includes PR:5573: webserver: improved caching control (see discussion)
  • Includes PR:5599: filesystem: add COverrideFile/COverrideDirectory to reduce code duplication
  • Includes PR:5625: Fix library clean/scan after #5324 when started from a remote.
  • Includes PR:5647: Honor "ignorethewhensorting" when jumping to letter
  • Includes PR:5655: [NfoFile] fix empty video details for multipart episodes
  • Includes PR:5660: Fix SMB files reading on POSIX platforms
  • Includes PR:5665: fix CApplicationMessenger::SendText() not sending the text to the proper edit control (see post)
Build Highlights:
  1. New firmware with support for audio formats that need applying a shift to the data:
    popcornmix Wrote:I've hopefully fixed the GPU resampling causing white noise with I2S audio cards (like hifiberry).
    There's a small chance it could affect audio in other situations, so let me know if anything sounds bad.
    (I've been through quite a full set of codecs and it seemed fine to me)
    This has been tested with Raspbian+3.12 kernel. Hopefully the problems with Hifiberry hardware and the 3.17.2 kernel will be solved sooner than later.
  2. Added: PR:5660: Fix SMB files reading on POSIX platforms (no longer need to revert e502b099 to prevent ISO/IFO over SMB segfault)
  3. Added: PR:5665: fix CApplicationMessenger::SendText() not sending the text to the proper edit control
Build Details:
  1. Firmware (Nov 6):
    • firmware: audio_mixer: Add support for applying a shift to the output data See: link
    • firmware: Some upstream improvements for memory compaction of relocatable heap
  2. OpenELEC:
    • sundtek: transformed to service addon (PR:3458, 1 commit, 14 files changed)
    • sundtek-mediatv: here is a nice joke... (9d253c15)
  3. XBMC:
    • [jenkins] - fix wrong branchnames at times (PR:5659, 1 commit, 1 file changed)
    • [CEC] Added support for CEC buttons introduced by HDMI 1.4 (PR:5628, 1 commit, 4 files changed)
  4. newclock4:
    • New commits in this build:
      • [ResamplePi] Add support for formats that need shifting (4efc8e73)
  5. Additional commits/pull requests not yet merged upstream:
    • Added: PR:5660: Fix SMB files reading on POSIX platforms
    • Added: PR:5665: fix CApplicationMessenger::SendText() not sending the text to the proper edit control (see post)
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.
@popcornmix: I'm seeing the following warning when starting videos:
Code:
22:44:14 5426.990234 T:2682250304 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available

The warning come from the new commit "[DVDMessageQueue] Remove pi specific logging ifdef" added in #1105.

Some videos may show the above warning up to half a dozen times, although most videos only show it once or twice (most often for video, though sometimes also audio).

Anything to be concerned about? I haven't noticed any playback issues.
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.
Noticed the same thing, but seems to be working fine so far.
(2014-11-06, 05:23)gendo Wrote: here are new samples

https://dl.dropboxusercontent.com/u/5174353/S1.rar
https://dl.dropboxusercontent.com/u/5174353/S2.rar

Popcornmix are these samples good?
(2014-11-07, 00:50)Milhouse Wrote: @popcornmix: I'm seeing the following warning when starting videos:
Code:
22:44:14 5426.990234 T:2682250304 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available

The warning come from the new commit "[DVDMessageQueue] Remove pi specific logging ifdef" added in #1105.

Nothing to worry about. I just wanted to know why it is disabled on Pi. My understanding is this message occurs when the demuxer has no data.
This occurs when packets are being decoded quicker than they are arriving (e.g. reading from network).

I think the reason this happens in normal circumstances on the Pi (in omxplayer mode) is because the GPU has pretty large buffers for audio and video data,
so xbmc can actually process packets pretty quickly at the start of file. Once the GPU fifo is full, the packets are consumed at a more normal rate, and the demuxer
starts to queue up data (and the warnings stop).

I just wondered if it was worth disabling this message, in case there's a correlation of this message with some more interesting problem.
I'll leave it as it is for a few days, but will probably revert if nothing interesting shows up.
(2014-11-06, 00:50)Milhouse Wrote:
(2014-11-03, 19:11)kieranc Wrote: So, the Hifiberry dev has responded, saying he's tested a digi on 3.17 under raspbian and that it worked correctly. I've just tried the 1102 build and it's as before, but I'm using a DAC+ rather than the digi - I believe they're the same chips but could be relevant.

OpenELEC 5.0 Beta 1 with a 3.17.2 kernel is now officially released.

You could test this Beta release with your Hifiberry and confirm to the Hifiberry developers whether it works or not with your hardware. I've had a quick read of your discussion thread over at Hifiberry, but let me know if they come back with any suggestions or ideas.

Thanks, I'll keep chasing them. Looks like the problem affects the DAC+ (which I have) but not the Digi (Which the dev tested). I confirmed this by compiling 3.17 myself on raspbian, which behaved the same as OpenELEC. 4.95.1 and today's build both don't work, as expected.
(2014-11-07, 15:12)kieranc Wrote: Thanks, I'll keep chasing them. Looks like the problem affects the DAC+ (which I have) but not the Digi (Which the dev tested). I confirmed this by compiling 3.17 myself on raspbian, which behaved the same as OpenELEC. 4.95.1 and today's build both don't work, as expected.

Okay. Anyone with a DAC or DIGI (not the + versions)? Can you test if hifiberry works? Does GPU accelerated resampling also work?
(2014-11-06, 05:23)gendo Wrote: https://dl.dropboxusercontent.com/u/5174353/S1.rar
https://dl.dropboxusercontent.com/u/5174353/S2.rar

S1.rar seemed to remain in sync after glitch with or without the reverted commit.
S2.rar did seem to lose sync with current tree, and remained in sync with commit reverted.

So hopefully this is the same issue you are seeing. I'll try to investigate what happens to the timestamps.
(2014-11-07, 18:47)popcornmix Wrote:
(2014-11-06, 05:23)gendo Wrote: https://dl.dropboxusercontent.com/u/5174353/S1.rar
https://dl.dropboxusercontent.com/u/5174353/S2.rar

S1.rar seemed to remain in sync after glitch with or without the reverted commit.
S2.rar did seem to lose sync with current tree, and remained in sync with commit reverted.

So hopefully this is the same issue you are seeing. I'll try to investigate what happens to the timestamps.

Thanks. If you need more samples do let me know.
(2014-11-07, 19:05)gendo Wrote: Thanks. If you need more samples do let me know.

Here is the dump of the audio/video packets with timestmps:
http://paste.ubuntu.com/8870494/

Before the glitch both audio and video have timestamps of around 50202 seconds.
After the glitch the video jumps to 25 seconds, but the audio remains at 50202 seconds.

It appears that this continues indefintely.
The sample you gave only has about 3 seconds of data after the glitch. Could you capture one that continues for about 30 seconds after the glitch just to prove that audio does jump later.

Now, if we have lost packets during the glitch, and video timestamps jump by a random amount, but audio packets don't jump by the same amount then I don't know how we can play with the audio and video in sync.

I've asked FernetMenta for advice as I can't see a solution. Maybe there is some other message somewhere that describes the timestamp jump.
At the moment it feels like a bug in the PVR backend.
(2014-11-07, 20:01)popcornmix Wrote:
(2014-11-07, 19:05)gendo Wrote: Thanks. If you need more samples do let me know.

Here is the dump of the audio/video packets with timestmps:
http://paste.ubuntu.com/8870494/

Before the glitch both audio and video have timestamps of around 50202 seconds.
After the glitch the video jumps to 25 seconds, but the audio remains at 50202 seconds.

It appears that this continues indefintely.
The sample you gave only has about 3 seconds of data after the glitch. Could you capture one that continues for about 30 seconds after the glitch just to prove that audio does jump later.

Now, if we have lost packets during the glitch, and video timestamps jump by a random amount, but audio packets don't jump by the same amount then I don't know how we can play with the audio and video in sync.

I've asked FernetMenta for advice as I can't see a solution. Maybe there is some other message somewhere that describes the timestamp jump.
At the moment it feels like a bug in the PVR backend.

will capture longer samples first thing tomorrow morning. The problem is coming from the backend but with the commit of the 18th (or older versions such as gotham) video and audio recover immediately whilst with current builds they do not.. let me capture some longer samples.
  •   
  • 1
  • 128
  • 129
  • 130(current)
  • 131
  • 132
  • 156
  •   
  Thread Closed
 
Thread Rating:
  • 8 Vote(s) - 4.88 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)4.888