•   
  • 1
  • 129
  • 130
  • 131(current)
  • 132
  • 133
  • 156
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(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.

here are two long samples.. let me know if you need more or longer ones..
https://dl.dropboxusercontent.com/u/5174...sample.rar
https://dl.dropboxusercontent.com/u/5174...ample2.rar
(2014-11-07, 18:26)popcornmix Wrote:
(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?

I have a hifiberry digi and it doesn't work with 4.95.1. I haven't tested gpu accelerated resampling.

I'm getting the same error messages with this build as I've reported earlier on. Let me know if output from dmesg/lsmod under 4.95.1 can be of any use.

Fwiw: based on the error messages and pouring through the source the actual error seems to be produced by core.c when called from the wm8804 codec. As the hifiberry driver apparently depends on this codec it also fails.

Hence does anybody know what is meant when core.c produces error code "-517" and fails to get either PVDD or AVDD?

Best regards
reg. #1106

(2014-11-07, 00:36)Milhouse Wrote: PR:5660: Fix SMB files reading on POSIX platforms (no longer need to revert e502b099 to prevent ISO/IFO over SMB segfault)

The problem with iso's previously reported appears agian. I had no problem with previous build (#1105)

(2014-10-21, 22:17)Bohlendach Wrote: I have a iso-file, dvd-rip, with no menu. It does not start playing when it is located on my nfs or smb-share, but when I play it located on a USB-pin (ntfs) it starts playing. Others iso plays smoothly.

The log-file can be downloaded here

Edit: Build #1018 plays it, #1019 to 1023 does not.

Edit:
I did a random check on my iso's.

build #1019 to 1023: Some but not all with no menus does not start playing. All of those I checked with menus played well.

Build #1018: all seems to play fine
New OpenELEC Helix build: #1107
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.17.2 #1 PREEMPT Fri Nov 7 21:04:03 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Nov  7 2014 17:01:00
Copyright (c) 2012 Broadcom
version 3bd41a132583ec90e4a0410a4aa631d1e4e2d8ea (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141107210250-r19552-g9d253c1 [Build #1107]

Based on tip of OpenELEC master (9d253c15, changelog) and tip of XBMC master (dcdbe844, 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 (328fa653)
  • 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.
Build Highlights:
  1. New firmware
  2. xbmc/kodi-addon-xvdr updated
Build Details:
  1. Firmware (Nov 7):
    • firmware: hdmi: Fix for reported modes with hdmi_edid_file. See: link
  2. XBMC:
    • fix CApplicationMessenger::SendText() not sending the text to the proper edit control (PR:5665, 1 commit, 1 file changed)
    • Honor "ignorethewhensorting" when jumping to letter (PR:5647, 1 commit, 1 file changed)
    • [videodb] Fix deleting bookmarks from dialog for plugins. (PR:5644, 1 commit, 1 file changed)
    • fixed: cur_dts returned by ffmpeg is invalid most of the time so relay o... (PR:5661, 2 commits, 2 files changed)
    • ffmpeg: bump to version 2.4.3 (PR:5666, 1 commit, 1 file changed)
    • [videodb]: keep empty series if hideemptyseries=true (PR:5643, 1 commit, 1 file changed)
    • Fix SMB files reading on POSIX platforms (PR:5660, 5 commits, 1 file changed)
    • fix segfault when calling StopScript builtin with no parameters (PR:5664, 1 commit, 1 file changed)
    • [NfoFile] fix empty video details for multipart episodes (PR:5655, 1 commit, 1 file changed)
    • [Cosmetics] reserve window id's for skins (ca14ec10)
    • [win32] fix typo in NSIS installer creation (b1893b51)
  3. kodi-addon-xvdr:
    • [libxvdr] demuxer locking cleanup (bcd82ab1)
    • [libxvdr] cache availability of channelscanner (f49e8181)
    • [libxvdr] demuxer: remove oldest entries from queue on overflow (328fa653)
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-07, 22:58)Bohlendach Wrote: reg. #1106

(2014-11-07, 00:36)Milhouse Wrote: PR:5660: Fix SMB files reading on POSIX platforms (no longer need to revert e502b099 to prevent ISO/IFO over SMB segfault)

The problem with iso's previously reported appears agian. I had no problem with previous build (#1105)

Ahk, it's been merged now. Do you have a sample of an ISO that doesn't play over SMB with #1106 but which does with #1105?

Can you also provide a debug log from #1105 AND #1107 (upload both to pastebin), to see the difference in behaviour. I've posted a note on PR:5660.
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.
Something happened in either #1105 or #1106 (I skipped the first) which is causing existing library entries of DVD copies to be included again on a rescan with all containing VOB files to be added as separate movies. The movie name of the VOB files is being determined based on the file name, thus resulting in a massive list of bogus entries in the library.

Any idea which commit it causing it or do you know of the issue? Else I'm going to try #1105 as well to see if it occurs in that build already. I'd like to prevent this if I can because it's a PITA to manually remove all the entries one by one again.
If you can determine the build when the problem starts that will help. Also are you scanning over NFS, SMB, or something else?
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 here is a longer sample. here i waited till audio and video actually resume even though they stutter/seem slow
https://dl.dropboxusercontent.com/u/5174...ample3.rar

EDIT: Hmm actually i played these files in kodi and they work fine as in glitch and resume immediately! could there be something different in the path used by livetv? as during live playback this sample frooze for circa a minute..
(2014-11-07, 22:58)Bohlendach Wrote: The problem with iso's previously reported appears agian. I had no problem with previous build (#1105)

The next build will revert e502b099 once again - can you please test your troublesome DVD ISOs over SMB with both #1107 (shouldn't work) and tonight's #1108 build (might work?), and let me know the results.
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-08, 06:34)gendo Wrote: @popcornmix here is a longer sample. here i waited till audio and video actually resume even though they stutter/seem slow
https://dl.dropboxusercontent.com/u/5174...ample3.rar

EDIT: Hmm actually i played these files in kodi and they work fine as in glitch and resume immediately! could there be something different in the path used by livetv? as during live playback this sample frooze for circa a minute..

All three of your longer samples seem to have correct timestamps and play without pausing or out-of-sync issues for me.
S2.rar is the only file that has behaved badly for me (but based on the information available in the file, I don't know how it can be fixed).

There are many differences between watching live and playing the same file from a recording.
One obvious one is that a live source can only be read from in real time. A file can be read much quicker.
E.g. if the player's concept of time is ten seconds ahead of the demuxer, a live stream will pause for ten seconds. A file will be able to catch up much more quickly.

There are other differences in behaviour between live and file playback (e.g. in decisions made about buffering), and there's no guarantee that the PVR backend writes
the same data to the file when recording as it does when playing live.
New OpenELEC Helix build: #1108
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.17.2 #1 PREEMPT Sat Nov 8 21:01:44 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Nov  7 2014 17:01:00
Copyright (c) 2012 Broadcom
version 3bd41a132583ec90e4a0410a4aa631d1e4e2d8ea (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141108210034-r19562-g1c281cc [Build #1108]

Based on tip of OpenELEC master (1c281cc8, changelog) and tip of XBMC master (2d88a9a6, 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 (328fa653)
  • 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.
  • Reverted e502b099: Reason: may be responsible for ISO playback issues?
Build Highlights:
  1. Reverted: e502b099 - @Bohlendach, see next post
  2. Update to ffmpeg-2.4.3
  3. Bump to 14.0 Beta2
Build Details:
  1. OpenELEC:
    • curl: update to curl-7.39.0 (9297b047)
    • ffmpeg: update to ffmpeg-2.4.3 (d8ebd7ef)
    • projects/*/linux: disable USB autosuspend per default (592ee32d)
    • projects/Generic/linux: remove old commandline options (ba6fa6d4)
    • xorg-configure: dont count on tmpfiles (22d3a722)
    • systemd: add upstream patch (d8575b8a)
    • v4l-utils: update to v4l-utils-1.6.0 (f2ff885c)
    • v4l-utils: readd reworket patch to fix 'OTHER' protocol (91cac081)
    • v4l-utils: add support for user keytables in /storage/.config/rc_keymaps (1c281cc8)
  2. XBMC:
    • FIX: [droid] allow to build without debugging and pickup jenkins configuration (PR:5586, 1 commit, 1 file changed)
    • [infomanager] only call UpdateAVInfo when really needed (PR:5669, 2 commits, 2 files changed)
    • Revert "[infomanager] only call UpdateAVInfo when really needed" (PR:5673, 1 commit, 2 files changed)
    • [logging] stop log spam introduced with ba34a62 (PR:5670, 1 commit, 1 file changed)
    • [release] bump to 14.0 beta2 (PR:5642, 1 commit, 2 files changed)
  3. Additional commits/pull requests not yet merged upstream:
    • Reverted: e502b099: Reason: may be responsible for ISO 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.
@Bohlendach: Due to the unexpected critical changes between the last two builds, such as ffmpeg bump, can you compare #1108 (above, without e502b099) and #1108b (identical to #1108 but *includes* e502b099).
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-08, 20:40)popcornmix Wrote:
(2014-11-08, 06:34)gendo Wrote: @popcornmix here is a longer sample. here i waited till audio and video actually resume even though they stutter/seem slow
https://dl.dropboxusercontent.com/u/5174...ample3.rar

EDIT: Hmm actually i played these files in kodi and they work fine as in glitch and resume immediately! could there be something different in the path used by livetv? as during live playback this sample frooze for circa a minute..

All three of your longer samples seem to have correct timestamps and play without pausing or out-of-sync issues for me.
S2.rar is the only file that has behaved badly for me (but based on the information available in the file, I don't know how it can be fixed).

There are many differences between watching live and playing the same file from a recording.
One obvious one is that a live source can only be read from in real time. A file can be read much quicker.
E.g. if the player's concept of time is ten seconds ahead of the demuxer, a live stream will pause for ten seconds. A file will be able to catch up much more quickly.

There are other differences in behavior between live and file playback (e.g. in decisions made about buffering), and there's no guarantee that the PVR backend writes
the same data to the file when recording as it does when playing live.

Thanks for you answer. I tried a different backend box with different software and get exactly the same issue. Also i am playing live streams,no timeshift etc.

I made a further experiment, I placed two kodi + 1 vlc next to each other playing the same livetv stream Kodi 1 has the openelec build of the 18th (with commit) and kodi 2 is last nights build. I glitch the live stream and kodi 1 recovers within a couple of seconds, vlc does the same whilst kodi 2 remains stuck for over a minute.

Maybe you can add an optional parameter to add the commit of the 18th, or even better just use it for livetv since there should not be the timestamp issue found on the disc you were trying to address with the original fix, and anyway cannot jump on a live stream..

I also notice that there is a slight difference between raspberry pi and windows on the windows version it behaves exactly the same, but displays buffering 0% whilst the video is jammed on pi the video is jammed but buffering does not show on screen. In reality since this is a live stream do we need to resync (i.e. it is not like we can go back or forward in time like in a file)

I also downloaded a glitching stream straight from backend to to disk via chrome browser https://dl.dropboxusercontent.com/u/5174...-0-0-.mpeg as per your tests, this file works perfectly with and without the commit what i think is happening is that being a file, kodi can jump on resync, while for a live stream (not a stream like youtube where one can seek) after a glitch, kodi make a request to seek another portion of stream and that is not available and so gets stuck at buffering 0%
Thanks again for the continued development of openelec. This is absolutely fantastic and really amazing to see how magic this small device can be...

One question - will there be a stable openelec helix release? I would like to move away from moving nightlies and the upcoming Helix release may be a good moment to do so. Quite obvious how this works for OSX, Win7 et al, but not fully transparent how this works with the openelec builts.
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
(2014-11-09, 06:33)steve1977 Wrote: One question - will there be a stable openelec helix release? I would like to move away from moving nightlies and the upcoming Helix release may be a good moment to do so. Quite obvious how this works for OSX, Win7 et al, but not fully transparent how this works with the openelec builts.

Of course - OpenELEC 5.0 Beta 1 is now available, with a final stable release planned towards the end of the year. Just switch to the "official" beta/rc/release builds by dropping the tar into your Update folder 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.
  •   
  • 1
  • 129
  • 130
  • 131(current)
  • 132
  • 133
  • 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