For some reason my Orbiter crashes when I select Media - Video.The problem already occurred intermittently in the past, but recently I haven't been able to open the list of videos at all.

My experience was that this crash only occurs after my media director has rebooted. If I select Media - Video and it works, then it will stay working, otherwise it will crash immediately. Unfortunately, the last few days it always crashed

I suspect it may have to do with the number of video files that I have, since that is the only thing that (I think) has changed.Because I have not yet tagged all my videos I always switched to the Filename sort order. That may explain why subsequent openings of the video list always succeeded; because of the directory structure there wouldn't be too many files in it at once.

Anyway, I don't have any problems with Media - Audio, that one always works.

I checked the logging files, but I'm not experienced enough in LinuxMCE yet to make much of them. I included the sections I think are relevant below.

I think it might have to do with the access time for the video files. Maybe there is some kind of time-out being reached.The video files are on the server on a software raid (5) array, and there are over 4,000 of them.If I log into the orbiter and access the files from the command line (using a command like "du"), then afterwards I can retrieve the video list successfully.

Anyway, I have a work around now. I'll see if I can get any further with this.

The workaround does not seem to work I think it was a fluke that it happened to work twice in a row.

Any advice on how I can go on debugging this?

I can get tons of logging from the /var/log directory, from the screen session of the orbiter, and from wireshark. But that doesn't help if I don't know what I'm looking for. There are plenty of warnings/errors in the logging but most of them seem to be OK, or not very informative.

<snip a whole lot of "Cannot perform query because of Unknown column FK_Text">

Copyright (C) 2004 Pluto, Inc., a Florida Corporationwww.plutohome.comPhone: +1 (877) 758-8648This program is distributed according to the terms of the GNU Public License, available at: http://www.fsf.org/licensing/licenses/gpl.html This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Public License for more details.---------------

Did you find a solution to the problem? I have/had the same problem. You can also find the same problem reported here (http://forum.linuxmce.org/index.php?topic=9581.0). A reinstall with deleting all the id3 & key files solved the problem for now. It seems that the cover-art is the problem. I just wanted to check if you found a solution to the problem before I start adding cover-arts back in the database. Thanks.

I didn't really find a solution, a re-install seemed to help. Most of the meta-data and cover art was automatically re-entered into the data base, but some of it disappeared after the re-install.I have my media in a directory structure (for historical reasons, I know it's not the LinuxMCE way, but until I have entered all the meta-data it is the easiest way for me to find my media), and to ease navigation I gave the directories containing a movie the same meta-data (and cover art) as the movie inside it. This meta-data of the directories (or at least the cover art) seems to have disappeared for some directories, I still have to look into that.

I also have to say that originally my media was on an ext3 file system on an LVM volume on top of a Raid 5 array. During the install I took the opportunity to reorganize that to ReiserFS directly on the Raid 5 array, without LVM in-between.That might have speed things up enough to solve the problem for now, but I am afraid it might return as soon as I start adding more cover art again.

I just devoted a little time towards finding the exact issue, and I believe that I might have found part or the exact issue. I believe that the id3 Tags are the Issue. A copy of the picture is stored in each Id3 Tag file. This is additionally to the Thumbnails and "real" picture that is stored under mediapics. This increases the id3 file size & this should be the problem for the orbiter crash due to the increased reading time (According to WIKI, LMCE shows the pictures from mediapics, so the actual picture is not the problem).

Unfortunately, I do not have the time (getting back into programming plus understanding LMCE structure) to resolve this issue. I do not know the whole structure under LMCE, and it is very hard to understand all the connections if you start late in the game to understand the complex structure of this fantastic product. This is why I do not know if this is an easy fix (as I believe that it would be for the original programmer of a feature) or a complex task. One way would be to allow users to upload files through the Cover Art feature. The other way would be to allow the user (through a checkbox or something similar) to decide whether or not to save the picture in the id3 Tag (This seems to be a simple fix if-else statement, but this might be contrary to the LMCE concept or it might cause problems with other features). I might try to do it myself depending on my understanding of the LMCE structure & me getting back into programming.

I hope that this is the actual culprit. I will add this finding to the ticket.

As far as I know (and I'm no expert, even though I've been contributing for a year or so now ), the files themselves is not accessed when displaying the file list. If you have any indication that this is the problem, please elaborate.

I know the database queries haven been discussed a bit, as they weren't optimized in any way. I don't know whats come of that, but that may also be part of the problem.

I don't think there is any particular reason or guideline as to why the cover art is stored in the file. But LMCE syncs every other attribute, so why not the picture as well. (bytes these days are cheap anyway, and whats another 100k to a 3-4MB file, or 30-40 in the case of flac, my favourite ).On the other hand, options is always good to have, so feel free to dive in