[Milhouse]

I generally stick to stock Confluence with these Gotham alpha builds - there's so much change and subsequent breakage going on that its tough for the skinners to keep up (though a few are now starting to release Gotham-compliant skin updates). I wouldn't be surprised to see a Frodo skin messing up Gotham settings given the level of changes in that area.

[Trixster]

BTW, is skin.widgets a bit dodgy with the latest build? It seems to work fine under Confluence but not Confluence Modified.

/edit Sorry, just realised that Confluence does not use skin.widgets. The question still stands, is skin.widgets bust with the latest build?

[Reddog999]

@MilhouseVH

Can you please confirm if this commit of 5 days ago was included in your latest build (r16483) or not.

If it was included then I'm afraid it didn't bring the gpio receiver back to life as I would have hoped (unless we're meant to make any changes to the autostart.sh file).

If it wasn't included, I assume your next build will?

EDIT: forget all this - the lirc_rpi.c is the same as in previous versions. I guess I just got excited when I saw a recent commit that was related to the gpio receiver.

Yes, that patch is included in the currently available build. You say it was committed 5 days ago, however that patch appears to have been included in OpenELEC 4.0 for quite some time (at least 3 months, looking at my previous builds - the patch originated back in 2012). It may even be in 3.x builds.

Edit: In fact, that lirc/gpio patch has been in OpenELEC since 28 Feb 2013, if not earlier, in one form or another. So if your GPIO is not working you may be barking up the wrong tree with respect to that particular patch.

Yes, I see what you mean - I just saw the note that popcornmix committed the change 5 days ago. I'm not used to the intricacies of the github.
However, did you you see my 2nd edit where I said:
"In addition, I see that there were other changes made recently i.e. "lirc_rpi: Don't register with lirc_dev if we can't claim gpio pins" - I wonder if this could be a timing issue with registering the driver if it doesn't "claim the gpio pins" quickly enough?"
Do you think that is a plausable tree to bark up? link

[allan87]

Yeah, I tried deleting guisettings. I then reset all my settings back as before, rebooted and am back to 0.5 pixel ratio again. I'm starting to think it's an issue with the latest version of Confluence Modified which is a fault.

Following the instructions in Post: #1723 will address this problem. It takes guisettings out of the picture.

I believe you will find that, if you want to test, that starting from a fresh guisettings file, you won't have the 0.5 pixel ratio issue as long as you never use the gui calibrate feature. While this may be unsatisfactory because of excessive overscan, that can be corrected in config.txt, as indicated above.

[Trixster]

Hi allan,

Yes, that does seem to work. I didn't pay too much attention before, sorry. I'd still like to know what it is that is forcing an over-write of the settings in guisettings on every reboot which causes the pixel ratio for 1920x1080 resolutions to default to 0.50000 though....

[evanspae]

Yeah, I tried deleting guisettings. I then reset all my settings back as before, rebooted and am back to 0.5 pixel ratio again. I'm starting to think it's an issue with the latest version of Confluence Modified which is a fault.

Following the instructions in Post: #1723 will address this problem. It takes guisettings out of the picture.

I believe you will find that, if you want to test, that starting from a fresh guisettings file, you won't have the 0.5 pixel ratio issue as long as you never use the gui calibrate feature. While this may be unsatisfactory because of excessive overscan, that can be corrected in config.txt, as indicated above.

allan thank you so much for this after a little tweaking of config.txt I have indeed got over this problem. You are also quite correct about deleting original guisettings.xml, I suggest your post #1723 should read

1. boot rpi
2. delete guisettings.xml to remove earlier anomolies
3. reboot
4. Edit guisettings to delete everything from <resolutions> to </resolutions>, inclusive
5. Insert <resolutions /> in the place of the (many) lines you just deleted.
6. save
4. login to the pi over ssh
5. type 'poweroff'
6. insert your SD card into your computer, to edit the the overscan settings in the config.txt file.
7. make all necessary adjustments other than calibration from gui

As a tool to do this from a windows I recomend MobaXterm Personal Edition v6.5 it allows a simple means of accessing the pi and has a built in editor

[Milhouse]

BTW, is skin.widgets a bit dodgy with the latest build? It seems to work fine under Confluence but not Confluence Modified.

/edit Sorry, just realised that Confluence does not use skin.widgets. The question still stands, is skin.widgets bust with the latest build?

Yes there's a recent commit referring to a fix for skin widgets, I'll put up a new build later today.

[stuCONNERS]

are these gotham builds stable enough for daily use or is it still better to stay with frodo for the time being?

[rterblanche]

Stable enough to use but do have a few features that you have to work around.

Also depends on your installation. (PVR,etc)

[popcornmix]

are these gotham builds stable enough for daily use or is it still better to stay with frodo for the time being?

Don't use Gotham if Frodo does all you want and things must always be stable.
Don't use Gotham if you predominantly use add-ons.

Use Gotham if you want to help with testing.
Use Gotham if there is a specific bug on Frodo that is resolved on Gotham.
Use Gotham if you want better performance and new features and don't mind occasionally reporting bugs, and reverting to an older build.

The basics tend to always remain stable, e.g. playing locally attached or streaming from local network.
Add-ons do break when APIs in Gotham change, until the add-on maintainers catch up.
PVR backends do break when APIs in Gotham change, until the PVR backend maintainers catch up.
Gotham is a development tree. Minor bugs frequently appear and then disappear a few days later.
The first ten days of each month are when new features are added.
The remaining days are only bug fixes, so generally updating at end of a month is more stable than updating in first ten days of the month.

Currently the GUI sounds are a bit experimental and it may be worth waiting a few days before switching.

[Leopold]

are these gotham builds stable enough for daily use or is it still better to stay with frodo for the time being?

Don't use Gotham if Frodo does all you want and things must always be stable.
Don't use Gotham if you predominantly use add-ons.

Use Gotham if you want to help with testing.
Use Gotham if there is a specific bug on Frodo that is resolved on Gotham.
Use Gotham if you want better performance and new features and don't mind occasionally reporting bugs, and reverting to an older build.

The basics tend to always remain stable, e.g. playing locally attached or streaming from local network.
Add-ons do break when APIs in Gotham change, until the add-on maintainers catch up.
PVR backends do break when APIs in Gotham change, until the PVR backend maintainers catch up.
Gotham is a development tree. Minor bugs frequently appear and then disappear a few days later.
The first ten days of each month are when new features are added.
The remaining days are only bug fixes, so generally updating at end of a month is more stable than updating in first ten days of the month.

Currently the GUI sounds are a bit experimental and it may be worth waiting a few days before switching.

Nice summary.

I thought Gotham was now in feature freeze so this month will just be bug fixes? Does that mean that GUI sounds for RPi won't be accepted for Gotham?

Are the changes in the newclock3 branch planned to be merged for the Gotham release or at a later date?

[popcornmix]

I thought Gotham was now in feature freeze so this month will just be bug fixes? Does that mean that GUI sounds for RPi won't be accepted for Gotham?

It depends on the other xbmc devs. Some may consider lack of GUI sounds a bug that is being fixed, some may consider it a new feature.
In reality I expect OpenELEC, raspbmc and other custom builds to each have a set of out-of-tree patches (as they always have),
and if GUI sounds works well, and is wanted by users, then it will probably be picked up, even if not in Gotham tree.

So for most users, it won't make a lot of difference - it just creates some extra work for the xbmc build makers.

[User 99401]

@popcornmix

Hi, any ideas whether the subtitle issues are in work? shall we expect a fix sometimes soon?
thats the only part push me back from having this excellent build
thanks

[popcornmix]

@popcornmix

Hi, any ideas whether the subtitle issues are in work? shall we expect a fix sometimes soon?
thats the only part push me back from having this excellent build
thanks

I got some information from elupus so I know where to look next. Will try to do some work on it this weekend.

[User 99401]

@popcornmix

Hi, any ideas whether the subtitle issues are in work? shall we expect a fix sometimes soon?
thats the only part push me back from having this excellent build
thanks

I got some information from elupus so I know where to look next. Will try to do some work on it this weekend.

as always... Thanks!!!