Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - indulis

Pages: [1] 2
Users / Intermittent problems on startup of LMCE- solved
« on: January 12, 2009, 04:43:49 am »
I've been having a problem where I would have to reboot 3-4 times to get LMCE to start up fully.

Sometimes I would get "can't connect to database" and other mysql errors reported in the LMCE Launch Manager.  Other times the Orbiter Gen would fail or the Orbiter launch would just fail.

I knew it was unlikely to be hardware 'cos if I rebooted and it made it all the way through to Media Director and Orbiter startup, that the system would run 100% reliably for up to a week.

After a day or 2 of looking at the system, I found the problem- during mysql startup it runs a fast check of all the database tables.  One of the pluto databases was corrupted, and it was corrupted in a way that would actually crash the mysqld process when it tried to check it.  The mysqld process would immediately get respawned but anything that had already connected to the DB during bootup would be disconnected.

So I'd be getting messages about "can't connect to mysql using socket", but when I would try it myself from the command line it would work fine.

I found it by disabling the mysqlcheck in the mysql startup scripts, enabling error logging in the /etc/mysql/my.cnf file, and I could then see which DB table  it was crashing on.

Then just had to open the DB in mysql using the command line interface to mysql, and optimize the table.  This has fixed the table enough to stop it crashing with the mysqlcheck step.  But it is still corrupt in some way (logs reporting incorrect timestamps) so will have to do a full fix tonight and try to unload/reload the database.  From memory the table was "File". Can't remember which pluto DB, easy enough to find cd /var/lib/mysql/ then do a find . -name "File".

Of course, the symptoms make perfect sense now, any processes that were connected to the DB during bootup when mysql was in the middle of checking and crashed/respawned would be disconnected and fail.  As my DB tables for Myth grew it would take longer to check until it got to the point where it was hitting the right point in the bootup process to disconnect the processes started before the mysqlcheck.

Will append more "how to recover the DB table" once I've done it.

This was a real stinker of a problem- intermittent ones always are!

One thing which is a pain is that the "InnoDB" style of database whcih is being used for the pluto DBs and tables does not have the ability to recover by doing a self repair, unlike the ISAM databases which are used by Mythtv.  It'd be interesting to know why the InnoDB engine was used in stead of the ISAM engine (MySQL gives you a choice) as it seems from my initial reading to be less robust and an "old" way of doing things.

OK I was wrong about InnoDB- InnoDB has a lot more function such as row locking and ACID etc so it is v good to use this instead of ISAM.  Though you don't get the self-repair facilities of ISAM :-\

Users / How to make a Pioneer DVR-216 DVD drive region free
« on: December 07, 2008, 09:55:50 am »
Instructions are in the "Installation issues" DVD Region sticky.

Preliminary, for mid-experienced users i.e. instructions are not fully detailed leave out some "obvious" instructions like change directory, otherwise working.  I can now play region 1 and 2 DVDs as well as region 4!  Hooray!


A trivial fix to help those that have rebuilt their kernels, and to improve robustness.  A change to /etc/init.d/mythtv-backend is required to check for the existence of /proc/sys/dev/rtc/max-user-freq before trying to write "1024" to it.

AAt least in kernel, the RTC emulation by the new HPET facility does not extend to putting a fake entry to match the old RTC in /proc/sys/dev

Instead, you have to use

echo 1024 >/proc/sys/dev/hpet/max-user-freq

The start script should check for the existence of both rte and hpet before it tries to write to them.  Because it does not, if the write fails the script fails completely (ie mythbackend does not start).

If this script is within the scope of LMCE (if not whose it is?) I am happy to code this and would like to get some help on how to get a patch generated once I've changed the script, and how to submit it for inclusion to LMCE.

Installation issues / LIRC with rebuilt kernel- working!
« on: November 23, 2008, 04:11:17 pm »

I've put the steps required to get LIRC to work with a new 2.6.27 kernel in the Wiki.

The instructions only build one device module for a particular IR receiver.  This is because some modules won't build.

The only thing left to do is to figure out which modules won't build, and leave them out of the configure step.


PS my system has been amazingly stable on the new kernel, even compared to the previous version, *and* my tuners are rock solid instead of dropping out and requiring reboots to reacquire them

OK, I got a new kernel built ( and installed, along with the latext nvidia drivers (177.80) and latest V4L-DVB drivers.

My DVB tuners seem MUCH more stable, and most LMCE things seem to work, will know more over the next few days.

/proc/dev/sys/rtc disappeared though which meant manually editing the mythtv-backend start script to get rid of where it tries to write to it. HPET (high precision timer) is supposed to create the rtc directory but it doesn't, though enabled in my kernel build.

Anyway, my MCE remote has stopped working.  I get the message box in the UI telling me that mce_usb2 is installed when I plug it in, and the MD has a device defined, but the remote has no effect.  Any ideas where to start troubleshooting?

Installation issues / SOLVED- stuttering audio for some HDTV programs
« on: October 08, 2008, 06:50:01 am »
I was getting weird audio stuttering and freezes during LMCE playing *some* recorded HDTV programs.  These would play fine using Mythtv or normal Xine, so I knew it was not hardware or the linux or alsa configs.

Anyway, I had to change /etc/pluto/xine.conf line from

This cured the problem.

Developers / Buggy behaviour with RAID devices- best way to deal with it?
« on: October 06, 2008, 07:05:52 am »

I have an md RAID device for /, and another for /home.  When LMCE starts, it puts a sym link to the / and /home devices into /home/public/data/others, then UpdateMedia goes into an endless loop going up and down the directory tree as it tries to scan for files.  That is, you go down to /home/public/data/others/md4_SYMLINK which is a sym link back to the device that is mounted as /home, then you go down again to what is now

 /home/public/data/others/md4_SYMLINK/public/data/others/md4_SYMLINK then does it again again


I've changed the actual Symlink name to make this more readable.

I have looked at  3 places where this could be fixed:

1) which takes all of the disk devices and creates the symlinks.  What I'd do here is check before making a symlink that it does not point further towards /  . In other words, if the link is being put in /home/public/data/others, then the link should not point to a disk/raid device that is also mounted at a higher point in the same path.  That is, no link should point to devices that are mounted on /, /home, /home/public, /home/public/data, or /home/public/data/others or an infinite loop will result.

2) in where the system checks for RAID storage, knock out any devices associated with a RAID device that is already mounted

3) Change UpdateMedia so that it recognises when it starts to recurse and jumps out.  WOuld not have to be perfect, could keep last say 255 devices that it scanned in this scan, and check that a directory transition does not take us to a device where we've been before.  If it is a new device just add it to the list.

Which should I do?  I am leaning to #1, as it means RAID devices ares still discovered, but UpdateMedia can cope as it doesn't have to transit infinite loops.  Is there any other use for the symlinks apart from UpdateMedia?



Installation issues / Separate / and /home filesystems cause problems?
« on: October 05, 2008, 08:00:30 am »
I have set up my system with a separate (RAID1) / and RAID1 /home.

These are the messages I am getting from Xine.  It looks like the Media Update engine is looping, and can't recognise that /home (Device 43) is mounted under / (Device 26)

Code: [Select]
[size=10pt][/size]05      10/05/08 13:34:41.970           ^[[33;1mOpening media FAILED^[[0m <0xb6e32b90>
05      10/05/08 13:34:41.970           ^[[33;1mXine_Stream::OpenMedia failed! Aborting!^[[0m <0xb6e32b90>
05      10/05/08 13:34:41.970           ^[[33;1mXine_Player::CMD_Play_Media() Failed to open media^[[0m <0xb6e32b90>
05      10/05/08 13:34:42.972           ^[[33;1mXine_Player::CMD_Play_Media() ended for filename: /home/public/data/other/Software Raid 1 [26]/home/public/data/other/Software Raid 1 [43]/public/data/other/Software Raid 1 [26]/home/public/data/other/Software Raid 1 [43]/public/data/other/Software Raid 1 [26]/home/public/data/other/Software Raid 1 [43]//1007_20080929112700.mpg with stream 0x87413e0.^[[0m <0xb6e32b90>

Here is my mount table (the relevant bits)
Code: [Select]
rootfs on / type rootfs (rw)
/dev/md0 on / type ext3 (rw,data=ordered)
/dev/md0 on /dev/.static/dev type ext3 (rw,data=ordered)
/dev/md1 on /tmp type ext3 (rw,data=ordered)
/dev/md4 on /home type jfs (rw)
/dev/md4 on /mnt/device/43 type jfs (rw)
/dev/md0 on /mnt/device/26 type ext3 (rw,data=ordered)

I am about to set "ignore" on device 26 (/ filesystem) which I am hoping will stop the looping.

Installation issues / Setting up shepherd for Australian grabber [SOLVED]
« on: October 05, 2008, 04:18:43 am »
    Had some issues with the normal mythfilldatabase job and Shepherd (and Oz tv listing grabber). Permissions etc.  This has resolved them easily and is the recommended shepherd way of running.

    Solved it by doing this:

    • sudo passwd mythtv
    • sudo su - mythtv
    • mkdir .shepherd && cd .shepherd
    • wget
    • sh /home/mythtv/.shepherd/shepherd
    • Run through the setup process, and allow shepherd to set up mythtv and a cron entry to run mythtfilldatabase (as mythtv user).  Note that one step fails: where it tries to to create a symbolic link from /usr/bin/tv_grab_au to /home/mythtv/.shepherd/shepherd
    • create symbolic link manually:
      • sudo mv /usr/bin/tv_grab_au /usr/bin/tv_grab_au.old
      • sudo ln -s /home/mythtv/.shepherd/shepherd /usr/bin/tv_grab_au
      • Use mythtv-setup from a terminal window to disable the mythfilldatabase job ('cos cron will do it instead)
    Hope this helps someone!  Will put it into the  Wiki as well.

    Note that log files for mythfilldatabase will now go to /home/mythtv/.shepherd/log dir.  I will look at how to fix this in the next day or 2.

Users / Should UpdateMedia use up lots of CPU?
« on: October 02, 2008, 12:28:16 pm »
This seems to be running a LOT on my system.

I think it may be because I defined a RAID-1 partition (md4) by booting into standalone Linux and manually creating it.  Then booting LinuxMCE it had problems mounting it (I put a wrong option into /etc/fstab).  I am mounting the partition over /home.  It is JFS.

Think LinuxMCE deteced the partition at first boot and assigned it a device number (before I ficed the mount problem).  Now it is mounted properly as /home.

Could it be because LMCE is updating files in /home, which then trigger a rescan because it is also a disk device?

I am away from home right now so can't give more details.

Now I have LinuxMCE going, and its use of  Mythtv is driving me up the wall.

The problem is that if all tuners are used, LinuxMCE keeps trying to set Mythtv to LiveTV mode, and 'cos it get a bad return code from Mythtv it just keeps trying.

Could it please
1) just give up immediately instead of retrying
2) Not try to go directly into LiveTV- Mythtv main menu should be good enough
3) Give the user a configurable option as to whether they want it to go to Mythtv LiveTV or Mythtv Menu (maybe even which menu?)

There is another horrible side effect that if you choose the option in MythTV to always go to program schedules instead of LiveTV (ie with PIP display of LiveTV and rest of screen is program guide) then LinuxMCE loops.

It is also possible that this is my problem , not LinuxMCE's.

Developers / Wiki- can't create thumbnails today
« on: September 27, 2008, 12:29:11 pm »

Couldn't find a bug report or feedback link in the Wiki.  I uploaded an image of a computer case (am reorganising the recommended hardware into main pages and templates for the common sections, so that we don't have 3 different spots with the same recommendations for a product).  Now when I try to embed an image thumbnail I get this in the image box
/usr/bin/convert: No such file or directory

Suspect imagemagick has not been reinstalled, or has not been linked to /usr/bin which is where mediawiki expects to find it

The wiki page is Template:Mid-size HT style cases

The image it is trying to convert is definiteyl there, cos if I remove the |thumb| section from the image link it comes up in glorious widescreen technicolor.

OK, I have checked that AVWizardDone = 1 is in /eytc/pluto.conf, so it is not AVWizard.

What is rewriting xorg.conf?  I can't get to test my changes because the standard one crashes X before the Orbiter starts up, I change it, reboot and there I am back to the same "standard' xorg.conf.

This makes it very very hard to try to get new hardware combinations working. 

Does anyone have a hint?

Was cursing how slow the UI was on LinuxMCE (grumble... what did they do to the YouTube video to make it look good... speed it up?).

Then I noticed that the red "receiving IR" LED was on all the time on the MCE USB receiver.

Moved it into a dark spot away from light from the fluorescents and everything suddenly sped up.  I am talking response times going from 10 seconds from button push on the remote until the UI registered it, down to instant.

I am thinking that the receiver was getting a lot of noise and causing a huge amount of traffic into the USB port.

Also, have had plasma TVs do the same sort of interference (though it did not cause the same slowdown as it was to an IR repeater unit).

Users / Change WIKI hardware section on motherboards?
« on: September 16, 2008, 07:07:32 am »
The Wiki hardware section on motherboards is useful as a "yes it works"/"no it doesn't".

It is not useful at all from the point of view of figuring out if a new motherboard or variant of an existing one will work, or how much of it will work.

I'd propose that the motherboard section takes each motherboard and breaks it down into the chipsets on it, then there are just pointers to info about that chipset.

For example,

Motherboard A
- Sound: ALC889A -> (points to separate page about this chip)
             working on this motherboard? Y/N

Or maybe this just means a separate set of hardware entries for chipsets?

I know the process I go through to select a motherboard is quite involved.  I am happy to start the ball rolling and document the process and the chipsets.

PS is there a way to invoke some sort of script to automatically get motherboard info from other web sites and past it into the Wiki.  Not that there is such a script, am just after ideas on *how* this could be done

Pages: [1] 2