[wsnipex]

auszig, pulseaudio is evil if you don't absolutely need it uninstall pulseaudio and libasound2-plugins.

You might also want to try a nightly from https://launchpad.net/~team-xbmc/+archive/xbmc-nightly
as there was a commit that might help with your situation.

[lcapriotti]

>and stopped udevtrigger

everyone going this path should keep in mind that a system upgrade may overwrite lightdm.conf, and revert it back to original.

A proper solution would be to identify a patch to the custom xbmcbuntu upstart jobs, which we control. Not being able to reproduce the issue I am not in the position to fully debug this.

[auszig]

auszig, pulseaudio is evil if you don't absolutely need it uninstall pulseaudio and libasound2-plugins.

You might also want to try a nightly from https://launchpad.net/~team-xbmc/+archive/xbmc-nightly
as there was a commit that might help with your situation.

Woohoo removing pulseaudio entirely has solved my problem.

I had tried killing the pulseaudio processes before starting xbmc but that didn't work. Damn right it is evil!

Thanks.

[WickdTrns]

Great!! Glad you got yours worked out too!

[gr8r-x]

you could try editing your /etc/init/lightdm.conf

edit this part, adding "and stopped udevtrigger"

I'd just like to say that this fixed it for me as well.

Would appear that maybe it's an issue with nVidia HDMI and using SSD's? Booting too fast for something I guess. Bit of a shame, but it works none the less, so thanks!!

[wsnipex]

everyone that used the "and stopped udevtrigger" method. Beware that an upgrade of lightdm will probably revert this.
I'm still thinking about a cleaner, more permanent solution. If you don't need lightdm(because you don't even have a desktop installed) you could switch to an upstart script for xbmc directly.

[Hack_kid]

>and stopped udevtrigger

everyone going this path should keep in mind that a system upgrade may overwrite lightdm.conf, and revert it back to original.

A proper solution would be to identify a patch to the custom xbmcbuntu upstart jobs, which we control. Not being able to reproduce the issue I am not in the position to fully debug this.

ok this might have already been covered but either use my upstart script from the automaticed minimal install script thread or add that same line and stopped udevtrigger to your upstart script up at the top. thats all thats needed as far as i know that tells the script not to start the process until the event udevtrigger is done which i think has something to do with loading devices (hence the dev) in the name