[popcornmix]

Ok maybe have to clarify that is live-tv i`m talking about. But here is 2 diffrent recording samle. One with ac3 audio and one with mpeg audio
https://www.dropbox.com/sh/wazyaax5ak09044/dc8QiGQSmz

I was assuming this came from a change in codec in the broadcast stream (e.g. at adverts).
If so can you record a file with this change in (which should also fail) so I can reproduce the issue.

[doveman2]

core includes the L2 cache that the ARM uses, so does make a noticable difference.
For arm speed, arm_freq is most important, then core_freq, then sdram_freq.

Thanks for the info.

Thanks.

I tried

arm_freq=900
core_freq=333
sdram_freq=450
over_voltage=2

and it was OK playing video and audio files but then I tried to view a picture (bmp) (all from the internal USB) and it took a long while to open and shortly after XBMC restarted, with that "Remote Communcation Server - Failed to connect" error again (what is that about anyway?).

Unfortunately I'd just turned debugging off so the log probably isn't very useful http://pastebin.com/hiR2pGRQ

Even with only

arm_freq=900
over_voltage=2

I found it still restarted when I pressed back to exit from viewing the picture.

I tried re-enabling Debugging and then it was restarting XBMC just navigating to the folder on the USB, without even opening the picture but when it restarted Debugging was off again (it was also asking if I wanted to keep this resolution when going into settings as well) so I had to enable it and reboot. After that, it seems OK when navigating to the pictures folder, viewing pictures or pressing back to exit the slideshow but it's still a bit worrying that this happened and I'm not sure it's stable enough to hand over to my brother yet.. http://pastebin.com/Q9Lfq6NN

If it was just a software bug I'd probably give it to him as I can always tweak it remotely but for all I know it could be the board can't handle overclocking and as you know, XBMC really needs it to be overclocked to be bearable so if that is the problem, I might need to try another board to find one that works stable overclocked.

---

If you're bumping up your sdram_freq, you probably also want to increase your over_voltage_sdram to avoid memory corruption.

Thanks for the tip. I'm going to concentrate on getting it stable with just the arm_freq overclocked for now, then try the others.

[Jönke]

Ok maybe have to clarify that is live-tv i`m talking about. But here is 2 diffrent recording samle. One with ac3 audio and one with mpeg audio
https://www.dropbox.com/sh/wazyaax5ak09044/dc8QiGQSmz

I was assuming this came from a change in codec in the broadcast stream (e.g. at adverts).
If so can you record a file with this change in (which should also fail) so I can reproduce the issue.

Its not possible to change channel when you are recording.
But it has nothing to do with adverts cause it´s always happening when go from a channel with ac3 audio to a channel that has mpeg audio.

[Koloss]

Updated Gotham Branch

- updated firmware and kernel (3.10.2)

- updated Xbmc 13 Gotham

- new bussy spinner

- avoid flushing fifos when audio/video fifos out of sync

- fix the non-trivial dirty rectangle modes

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

http://lysin.me/rbej

+ Starttimes of movies a little bit faster

- i cannot restart xbmc, when i click restart after i must disconnect the cable of pi
in openelec official builds it running

Next up the longtime test from me

[JoeSchmuck]

I guess I'm a bit surprised no one is doing a clean install of these changes and are all doing an upgrade. I guess I will perform an upgrade and post how it goes. Maybe the NTP server data will be there. Now I need to run off and figure out how to do an upgrade, I'm sure it's in a document somewhere.

[popcornmix]

By the way this build has support for non-trivial algorithmdirtyregions (1 and 2)
E.g.

Code:

<advancedsettings>
   <gui>
       <algorithmdirtyregions>1</algorithmdirtyregions>
       <nofliptimeout>0</nofliptimeout>
   </gui>
</advancedsettings>

In theory it could speed up the GUI (or make it slower). Report any findings.

[mcarni]

Guys,
I guess I need some help.

from some releases ago I am starting to have a strange problem.
while trying to play a video file (i tried several .mkv files) I get only the audio but no video.

I tried to start from scratch with a blank userdata but still no video. I tried to play with vertical blank sync and/or with adjust display refresh rate settings but still no success.
In some cases no audio and no video, but in most of the configurations I tried I get only the audio and the video is like hidden behind the fanart or xbmc menu.
I can activate the onscreen playback menu and I see play, pause etc, but no way to get the video.

I tried to revert back to confluence skin and I tried the latest gotham as well as some older releases

I uploaded my last log to the following pastebin
http://pastebin.com/BKPM143V
is there any kind person that would like to help me out
Thanks a lot

M

[popcornmix]

I uploaded my last log to the following pastebin
http://pastebin.com/BKPM143V
is there any kind person that would like to help me out

You seem to have some out of memory errors. Can you try rebooting?

[mcarni]

I uploaded my last log to the following pastebin
http://pastebin.com/BKPM143V
is there any kind person that would like to help me out

You seem to have some out of memory errors. Can you try rebooting?

sure,
I rebooted several times but no luck...
this is the update log:
http://pastebin.com/D91JETb3

let me know if you need anything else
M

[allan87]

- i cannot restart xbmc, when i click restart after i must disconnect the cable of pi
in openelec official builds it running

Instead of disconnecting power, you might try SSHing to the Pi and issuing a reboot command in the terminal. I would expect this to be less likely to corrupt your installation.

[pootler]

would like to have some testers for this (Frodo / OpenELEC 3.1.3 based) build:
http://sources.openelec.tv/tmp/image/tes...r15163.tar

its mainly based on OpenELEC 3.1.3 with XBMC Frodo but with some Gotham backports from Popcornmix's Frodo backport branch. Any issues which are introduced with this build compared to 3.1.3 should be reported here. If it works (good) i will release this as 3.1.4 very soon.

thanks


Hi.......

this build seems very promising.

A.v sync is good most of the time, as well as apect ratio.

Not sure why but the''official'' builds always seem quite a bit faster than the rbej builds?? - not sure if its the fact I use USB as storage?

One annoying thing is that the ''playing now'' menu bar seems to intermittently show itself during any video inc Live tv?

Also the remote response throws a wobbly sometimes - for example in the live tv epg, it will skip to another channel and time for no reason.

This is not all the time.

haven't tried rbej latest but for me this is the best openelec build so far!!

many thanks

pootler

[popcornmix]

I rebooted several times but no luck...
this is the update log:
http://pastebin.com/D91JETb3

This is your problem

Code:

00:02:49 T:3061321728  NOTICE: ARM mem: 192MB GPU mem: 64MB

64M is not enough GPU mem for video playback. You want:

Code:

arm_mem=128

in config.txt.

[doveman2]

Is this included in the latest Gotham build? http://www.raspberrypi.org/phpBB3/viewto...&start=125

I'm wondering if it would fix my remote problems (occasional missing keypresses and phantom keypress loops).

[doveman2]

Had a lot of problems demonstrating with the 13/07 Gotham build at my parent's house today.

The network wasn't working at first, so it might be that some of the restarts (going into Pictures triggered them a few times) were somehow related to that.

Had a weird one where straight after scanning a folder of music into the library (empty before that) from a USB HDD, I couldn't play any of the tracks and it said not found, yet when I went to file view I could play them fine. Also one Album I tried to play (from fileview) was just skipping through at around 5s intervals. I tried a different Album and that worked fine. There tracks were all mp3 or wav so nothing exotic but it's possible the first Album files were corrupted I guess.

I hadn't cleared the Library of my own files (from a OS-mounted NFS share) before going over there, so I tried to Remove Source from file view for each of the two sources. It locked up both times. After rebooting the first Source was no longer showing, then I tried to remove the second one and it locked up again and after rebooting that was gone too. It was still going into Library and showing the same Albums/Artists though and I think I had to do Clean Library to get rid of them.

It may also be that I had a dodgy hub, as the one I was using at first, with the LEDs intact, was getting very warm around the usb sockets at the front. I've got an identical model that I disconnected the LEDs from so I swapped that in and it seemed quite stable after that (I removed the arm_freq=900 overclock as well though).I don't know if the heat with the first hub was coming from the LEDs or if it was some fault causing it. So it could have been a combination of no network, dodgy hub and some bugs that caused a lot of the issues.

Even without the overclock and second hub I couldn't get Poweroff to work though and it just left XBMC showing. I'm farily sure it had terminated that but wouldn't complete the rest of the shutdown process for some reason. I can't recall if I tried Reboot or if that worked. The remote mostly worked OK but did go into a phantom keypress loop once or twice.

[allan87]

Issues with recent builds:

For every build AFTER July 3, 2013, Myth PVR skipping is broken and unusable:
1. Playing back Live TV recordings with the Myth addon, big skip and commercial skip are broken. Instead of skipping, the playback hiccups for a second and resumes approximately from where you left off. Sometimes, the 30 second skip does not work either.
2. When you pause or skip, the display at the top corner right reports incorrect information. Sometimes it indicates a very short program length, just slightly exceeding the point you are in the show (like 0:15/0:17). Sometimes it reverses program length and position, and reports incorrect program length (like 7:22:00/1:15).

Re: Dirty Regions in 7/23 build, unfortunately, no benefit here.
Compared to <algorithmdirtyregions>3</algorithmdirtyregions> on the July 3 build,
- <algorithmdirtyregions>1</algorithmdirtyregions> uses marginally more CPU and the interface is OK, but not faster than before.
- <algorithmdirtyregions>2</algorithmdirtyregions> also uses marginally more CPU and the interface is noticeably slower.

The July 3 build was tremendous. Stable, responsive and functional.