• 1
  • 36
  • 37
  • 38(current)
  • 39
  • 40
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2013-08-31, 07:57)Huuh Wrote: What did you take out? This build seems to work with myth tv, live tv recordings.

Nothing, just followed this guide: http://wiki.openelec.tv/index.php?title=...spberry_Pi

with

PROJECT=RPi ARCH=arm XBMC=master make release (Gotham)

instead of

PROJECT=RPi ARCH=arm make release (Frodo)
Updated Frodo Branch

- [utils] Speed up sorting code used by library views

- [utils] Speed up url processing on music library

- GUILabelControl optimization

- GUIWindowSystemInfo optimization

http://netlir.dk/rbej/builds/

http://lysin.me/rbej



(2013-08-31, 04:57)MilhouseVH Wrote: With this patch applied to Gotham master, the following trailer, will buffer nicely and audio/video will show no problems until the very end, at which point the audio fifo (af) will show an increasingly negative amount, and playback will never actually finish (stuck on blank - black - video with silent audio), until STOP is pressed.

Can you try latest commit on newclock3 branch?
Just wondering if I'm doing something wrong with upgrading to Gotham versions? I'm copying KERNAL, SYSTEM and the MD5 files over to the update folder and rebooting from ssh.

Everything seems to go fine till it trys to update the System file and it will sit until eventually the screen goes black. Upon turning power on and off I get stuck at the Coloured bootscreen or sometimes it won't even boot.

I've also tried coping kernel and system to the sdcard and renaming kernel to kernel.img and still can't boot correctly.

System is running on USB with only SD to boot from. I'm downloading the new Frodo build and giving that a chance.
Sounds like SD card corruption. If you manually copy kernel.img (KERNEL) and SYSTEM to the SD card using a PC, don't forget to extract the firmware from the target folder too.
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.
(2013-08-31, 08:25)Neil Coggins Wrote: @popcornmix: here you go: Stargazing LIVE video - messed up BigStep

This file was recorded on tvheadend (v3.2 IIRC) on a debian squeeze system using a DD-Cine S2 V6 card back in January. We get roughly 5-10% of our recordings showing this BigStep issue (it used to be more like 25%, but for whatever reason - possibly upgrades to tvheadend? - it's not as bad nowadays).

I'm not seeing a problem with this file. It shows up as 38m duration and BigStep jumps in 10 minute steps.
Does the file misbehave when played directly, or only though tvheadend?
(2013-08-31, 13:31)popcornmix Wrote: Can you try latest commit on newclock3 branch?

Thanks, that seems to have solved the problem!
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.
Updated Frodo Branch

- [rbp/omplayer] Handle the case where EOS message fails.

- ffmpeg demuxer: fast channel change

http://netlir.dk/rbej/builds/

http://lysin.me/rbej



FYI

channel change in latest Gotham builds is fine 3 sec,
using newer frodo build channel change time up to 10 seconds, in latest build live tv don´t start up anymore.

Setup:
rpi 512, rbej build 31-08 usb install, Argus tv server (winpc), FloppyDTV card, wired lan.
(2013-08-31, 13:54)popcornmix Wrote:
(2013-08-31, 08:25)Neil Coggins Wrote: @popcornmix: here you go: Stargazing LIVE video - messed up BigStep

This file was recorded on tvheadend (v3.2 IIRC) on a debian squeeze system using a DD-Cine S2 V6 card back in January. We get roughly 5-10% of our recordings showing this BigStep issue (it used to be more like 25%, but for whatever reason - possibly upgrades to tvheadend? - it's not as bad nowadays).

I'm not seeing a problem with this file. It shows up as 38m duration and BigStep jumps in 10 minute steps.
Does the file misbehave when played directly, or only though tvheadend?

popcornmix, I'm seeing this in latest Gotham builds as well.
When pulling up the info, start time shows as 54Hrs and End time keeps growing when the playback proceeds.
As (to my best understanding) BigJump and SmallJump are derived from the remaining play time, when the playback proceeds and the EndTime grows, BigJump and SmallJump start to work OK.

This doesn't happen with Frodo OpenElec builds (3.0.6) - Maybe the change in FFMPEG?
Image
(2013-08-31, 14:33)rbej Wrote: - ffmpeg demuxer: fast channel change

I don't think this is usable on Frodo. It requires:
https://github.com/xbmc/xbmc/pull/1757
and probably other gotham commits.
(2013-08-31, 13:54)popcornmix Wrote:
(2013-08-31, 08:25)Neil Coggins Wrote: @popcornmix: here you go: Stargazing LIVE video - messed up BigStep

This file was recorded on tvheadend (v3.2 IIRC) on a debian squeeze system using a DD-Cine S2 V6 card back in January. We get roughly 5-10% of our recordings showing this BigStep issue (it used to be more like 25%, but for whatever reason - possibly upgrades to tvheadend? - it's not as bad nowadays).

I'm not seeing a problem with this file. It shows up as 38m duration and BigStep jumps in 10 minute steps.
Does the file misbehave when played directly, or only though tvheadend?

I am seeing the problem when playing the files over NFS as a normal video, i.e. not using the PVR addon.

I have just realised that I am not upgrading the firmware when I try the new Gotham versions... better try that first I think!

(2013-08-31, 00:07)allan87 Wrote: POPCORNMIX - Please note:
(2013-08-30, 23:54)Neil Coggins Wrote: I'm using a different skin (Amber), but it says the "finish time" as being roughly 1-2s in advance of the current time throughout, so yes - the time is not reported correctly.
Also, Neil, correct me if I'm wrong here, this occurs when you are watching on a Pi and the recording is being served by TVHeadend running on a PC, right?

Correct... although I get the problem just playing the same file off an NFS share on the server.
Re: Step/Seek/Skip problem:
(2013-08-30, 18:44)Neil Coggins Wrote: You will find that if you use BigStep repeatedly, the step size will gradually increase from the 1-2s until it reaches around 1m, and then (assuming your recording is long enough) it'll suddenly start working properly.
I can confirm that I have the same behaviour with Myth as is reported here re TVHeadend (and has been reported by Doveman respecting MediaPortal. The skip gets progressively longer as show proceeds, until the skips are the correct length.

NB: I reiterate that the recording time fields (as shown in confluence) are reporting incorrect information. The right hand field, which is supposed to be program length, shows the position in the recording. This number changes as playback proceeds. The left hand field, which is supposed to be the position, is a large number (many hours) and does not change.

Clearly, XBMC is extracting/reading and using the wrong numbers in several (if not all) PVR plugins, and it is at the root of this bug.
Doveman2 and Neil: If the skip problem is a major issue for you. I suggest that you try the Rbej July 3 Gotham build. That is the last one where skip worked correctly in Myth, and seems to be a very stable and capable build.
Updated Gotham Branch

- updated OpenElec build

- updated Xbmc Gotham

- updated firmware and kernel (3.10.10)

- updated PVR addons

[mythtv-cmyth] Release v1.8.12

Changelog:

Added 'Delete and re-record' menuhook
Added support for MythTV protocol 76 and 77 (MythTV 0.27)
Allow the backend to shutdown (by using monitor and playback connections)
Reduced startup time (Faster loading of channels)
Fixed start time for instant recordings
Fixed several smaller memory and multithreading issues
Refactored & cleaned up libcmyth (epginfo)

[iptvsimple] Release v1.8.1

Changelog:

Fixed issue with BOM header in EPG XML
Fixed issue with update channels if they are changed in m3u
Added setting starting number of channels

Some changes under the hood (cosmetics and improved finding data).

- omxplayer patches

[rbp/omxplayer] Support both analogue and hdmi audio
[rbp/omxplayer] Cosmetics
[rbp/omxplayer] Increase input audio buffer size to make better use of output buffer
[rbp/omxplayer] Increase audio buffer between arm and gpu
[rbp/omxplayer] Need to populate channel layout for passthrough
[rbp/omxplayer] Avoid audio codec when in passthrough modes
[rbp/omxplayer] Enable zoom and pixel ratio in video OSD
[rbp/omxplayer] Add Dynamic Range Compresssion scheme
[rbp/omxplayer] Handle the case where EOS message fails.

http://netlir.dk/rbej/builds/

http://lysin.me/rbej



  • 1
  • 36
  • 37
  • 38(current)
  • 39
  • 40
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223