Messages

106

Users / Re: Video Database Borked

« on: September 29, 2011, 06:12:33 pm »

This is weird. The following code run in a terminal reinstalled an empty media database. I restarted the orbiter and no videos appeared, as expected. I rebooted, and all my videos looked good - one copy of each. Then a few minutes later, all the duplicates reappeared.
So my thread title is wrong. Something is borked, that is borking the database.

Code: [Select]

/usr/pluto/bin/UpdateMediaDaemonControl.sh -disable

mysql -uroot

drop database pluto_media;
quit

cp /usr/pluto/database/media.sqlcvs .

/usr/pluto/bin/sqlCVS -D pluto_media -r media import

/usr/pluto/bin/UpdateMediaDaemonControl.sh -enable

107

Users / Re: Re-initialising/clearing the media database...

« on: September 29, 2011, 06:03:20 pm »

I just performed the procedure in post 26 and it worked great. No need to go to the launch manager, the first line of code stops the media daemon. I just went to KDE desktop and brought up a terminal. The only minor problem is that the "-disable" and "-enable" commands need to have short dashes, not long dashes. The following should work if you want to copy/paste into the terminal.

Code: [Select]

/usr/pluto/bin/UpdateMediaDaemonControl.sh -disable

mysql -uroot

drop database pluto_media;
quit

cp /usr/pluto/database/media.sqlcvs .

/usr/pluto/bin/sqlCVS -D pluto_media -r media import

/usr/pluto/bin/UpdateMediaDaemonControl.sh -enable

108

Users / Re: Has my sigate UK account been hijacked because of LMCE?

« on: September 29, 2011, 12:49:46 am »

Purps,

Nothing to add except my condolences. Simultaneous problems with MCE, VOIP provider, and SWMBO is the trifecta of pain.

Twodogs

109

Wiki / Re: Wikiworkgroup | Main topic

« on: September 29, 2011, 12:27:19 am »

Bongo,

I'm guessing that there are a few people who are really working hard on this, but a lot of your team is in wait mode. If you could give us your idea of the path to completion, then others could get to work. We could shift from a sequential effort to a parallel effort. In another post, you asked everyone to identify obsolete wiki articles. That's too broad. But if you said "Twodogs, go through all the Telecom wiki articles and identify the obsolete ones", then I could say "yes, boss".
So, even though we might not have the wiki structure in place yet, I think we should identify who will be responsible for what chapters. That's what I was getting at in my previous post. I don't care if you use the timeline I suggested - maybe someone else has a better idea. I just think that this is a big job and we need to get lots of people working on it.

Bongo, give us your idea of what we are embarking upon. I suggested a sequence a few weeks ago where you would be the supervisor, and the rest of us would be the worker bees. It also seems like you are asking for us to do things that I thought would come much later (rewrites and new content). I think the sequence below makes your life a whole lot easier and would get us up and running faster.

    Create the new wiki structure/framework (programming skills required)
    Identify the chapter leads (maybe one or two chapters per volunteer)
    Have each chapter lead fill out his chapter by cut/paste from existing content. The first level would come mainly from the manual. Second and third levels would mostly be wiki articles. This would be more of a sorting effort instead of a huge rewrite (which could take forever).
    Release the new wiki. Beers for everyone. There would not be much new content, but at least people could finally find what they are looking for (our biggest problem).
    Improve/Maintain. Once we have everything properly sorted and organized, we will discover many areas for improvements. This is where we can draft rewrites. The chapter leads can start tracking down the experts and asking for updates (making every effort to avoid bugging the devs).

110

Users / Re: Video Database Borked

« on: September 26, 2011, 08:22:22 am »

When I looked in /home/mediapics there were more than 11,000 coverart pics!

111

Users / [SOLVED (unborked)] Video Database Borked

« on: September 26, 2011, 01:01:36 am »

Trying to install a larger internal drive for media, but not doing a very good job!
- I let the system detect the new drive and install the LMCE file structure
- I then copied my videos (3 files per video, actually) from the old drive to the new
- Then I deleted the device for the old drive using LMCE admin

Now there are many duplicates of coverart for each movie, and I'm seeing all the installation videos and such.
Fixable, or do I need to reinstall?

Maybe this post might be what I need, but I can't even shut down LMCE from the launch manager (gives "KDE sudo error" popup)

http://forum.linuxmce.org/index.php/topic,6408.msg41219.html#msg41219

112

Installation issues / Re: Asterisk: External Phone Adapter not receiving inbound calls (Sipura 3x00, etc)

« on: September 20, 2011, 04:03:16 pm »

Have you looked at this?

http://wiki.linuxmce.org/index.php/Cisco/Linksys/Sipura_Analog_Telephone_Adapters

I had this happen to me, and discovered that I had a port number mismatch. In LinuxMCE admin, select Advanced -> Configuration -> Phones Setup. That brings up FreePBX. Look at the Extensions tab and write down the "Name" "Extension" "Password" and "Port" of your ATA. Then make sure this info was entered correctly into your ATA.

I bet that the main page of FreePBX looks something like the picture below. Notice that the top green bar (IP phones online) only goes halfway across the screen, when it should go all the way across. The number "1" to the right tells me that only one IP phone was working (the Media Director). When I checked the Extensions tab, it showed 2 IP phones (the Media Director and the new ATA I was trying to get working). So only 1 of my 2 IP phone was working - ergo the green bar only went halfway across the screen. My guess is that you are very close to getting things to work.

Another thing to check would be the "Telecom" dropdown from the LMCE admin page (near the top right of the main screen) and see if all settings look good.

113

Wiki / Re: Task | Draft Page Status

« on: September 17, 2011, 11:28:15 pm »

A lot of our current wiki articles assume a level of knowledge that many beginning and intermediate users do not possess (i.e. change the polarity on the flux capacitor and Bob's your uncle - it works!). I find that really irritating. If I knew as much as the author, I probably wouldn't be reading his wiki article. So it might be nice to include some verbiage in the template on the preferred level of detail. Something like...

"Wiki articles should be written with beginning users in mind. Readers should be provided an overview of what they are doing before being given a laundry list of steps to perform. If the overview already has already been covered elsewhere, a link to that source would be helpful. If no overview exists, then an introductory paragraph might eliminate repeated cries for assistance in the forums."

This is a pretty simple thing that will pay off in a big way. It makes LinuxMCE less intimidating to new users, so we will increase our user-base. It will also allow users to graduate more rapidly from beginner, to intermediate, to advanced, to developer. A larger and smarter user-base is nothing but good.

114

Users / Re: Conceptual Help

« on: September 14, 2011, 03:46:28 pm »

I would suggest running conduit from your basement to the rooms that will connect to the home automation system. I did this in my home and it has been a lifesaver. For instance, my wife moved her treadmill to another room and asked if I could give her a small tv screen to look at. I was able to pull sound and video cabling to the new location.
Just remember that Satellite TV will add complexity to your system (satellite box, hd pvr to get around encryption, possibly a matrix). Then all of these must be properly controlled (usually by rs232 or ir blaster). Then each of the LMCE templates must be set up correctly to ensure everything runs smoothly.

John

115

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: September 07, 2011, 03:39:44 pm »

Format looks good to me. However, the "awaiting review" and "confirmed" box brings up a potential problem. Do we have enough people, with enough skill, who are not devs, and who are willing to review all the wiki pages? I doubt that all of our "chapter lead" will have enough system knowledge to approve articles. Perhaps the best way to answer this is to give it a shot and see if the box gets filled out?

116

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: September 07, 2011, 03:04:26 pm »

I had not seen your draft page in a while. I vote for the second status box with the yes/no format. As for the type of page, I assume the template would have the three options with instructions to remove two? Seems pretty easy to me.

117

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: September 07, 2011, 03:53:56 am »

one for page type (instructional, overview, hack).

I would be interested in your views. One thing I will say - I think there need to be the bare MINIMUM of options for each of these fields

Agree that wiki contributors should have simple options from which to choose. Agree that hacks should be identified, but that doesn't necessarily mean we need another field. When we consider that a small percentage of wiki articles are hacks, and that hacks will be contributed by advanced users, then we might not want to make every Joebag'o'donuts wiki contributor fill out an extra field. Maybe we have two types of wiki templates - one for regular contributors, and one for hacks. The hack template could have a standard disclaimer at the top, be a different color, have different fonts, etc.

Also not sure we need to differentiate "instructional" from "overview".  The top level of each category would actually be the overview, then the instructional wiki articles would be in the second and third levels. For instance, when a newbie wants to install LMCE, said newbie clicks on "LMCE Installation Instructions" where he immediately sees something very much like the current "Quick Start Guide". http://wiki.linuxmce.org/index.php/QuickStart_Guide Much of this overview-type content would come from what is now the LMCE Manual. Only the administrators could modify it. If someone thought that the overview was inadequate, then they could submit their ideas to the chapter lead (or whatever we call them) instead of writing a wiki article. The second level of "LMCE Installation" would probably have a category called "Video Setup" among others. This would also have some video overview content along with access to third level articles like "black screen", "fonts too small" and such.

If the newbie is having a hard time getting his telecom gear to work during installation, he might decide to get really smart on the subject and could click entirely out of the "installation" chapter and into the "Telecom" chapter where there would be a good overview of the way telecom works in LMCE. With all his detailed questions answered, he could then return to the "LMCE Installation" chapter.

The overall concept is that we combine everything into a single source. Right now, if I want to learn about a subject I have to read the manual, then read the tutorials, then visit the hardware page, then read the forums, etc. And after doing all that, I do a Google search and find even more stuff! What I'm suggesting is one way to end all of that. All how-to content would fit into a 3-level wiki structure.
Here is a possible way forward, subject to the approval of Bongo and crowd.

• Create the new wiki structure/framework (programming skills required)
• Identify the chapter leads (maybe one or two chapters per volunteer)
• Have each chapter lead fill out his chapter by cut/paste from existing content. The first level would come mainly from the manual. Second and third levels would mostly be wiki articles. This would be more of a sorting effort instead of a huge rewrite (which could take forever).
• Release the new wiki. Beers for everyone. There would not be much new content, but at least people could finally find what they are looking for (our biggest problem).
• Improve/Maintain. Once we have everything properly sorted and organized, we will discover many areas for improvements. This is where we can draft rewrites. The chapter leads can start tracking down the experts and asking for updates (making every effort to avoid bugging the devs).

edit: Actually, I suspect that once we start sorting we might find that the second wiki level will be mostly or all overview, and only the third level will have user-submitted articles.

118

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: September 02, 2011, 07:59:38 pm »

I'm assuming it doesn't have to be a user-friendly method, as every page will go through a review process before it going into the main wiki? If so, that's another thing we need to think about - will the "approved" wiki pages be locked, so that new pages have to be created in a holding area or whatever before they are reviewed and introduced into the real thing?

Somewhere on the front page of the wiki, we should have a link called "Wiki Tutorial - Adding and Administering Content"

- In the "Adding Content" subheading, we would provide detailed instructions on how to create the perfect wiki article. We would have a link to the template everyone should use. We would give the authors the benefit of the doubt that they followed the rules, so there would be no holding area - a submitted article would immediately go up on the site.

- In the "Administering Content" subheading, we would have a table showing who is responsible for administering each major wiki chapter. Their first job would be move existing relevant articles into their chapter of the wiki. Administrators would periodically look at their wiki chapters for new content to make sure people are following the rules. If they found a problem they could fix it on the spot, get the author to fix it, or remove the article. If a particular chapter seems incomplete, an energetic administrator could go to the forums and request articles.

119

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: September 01, 2011, 03:33:55 pm »

We are beginning to gather a variety of different ideas - exactly as a brainstorming session should do. However, my thoughts are beginning to turn toward the practical. I'd like to know who is actually going to program the framework of our new wiki. What is his/her opinion of the technical difficulty of doing some of what we propose?

120

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing

« on: August 31, 2011, 03:51:26 pm »

Pedantic point 1: TV capture, what about the homerun? It should go under network with "NAS" for example, but then you want to keep TV hardware together.
Pedantic point 2: Do you think there is a blur between "automation" and "security"?


Generally speaking, personally I was keen to separate the "information" from the "hacks", and with your structure they will all be lumped in together. I think the "hacks" do have a place contrary to what some may think, but it should be made clear that they ARE hacks.

Lets pretend that I insisted that the Homerun should go under TV, and you insisted that it appear under NAS We could put it in both places, just as current wiki articles can be set up to appear in "tutorials" and "hardware". But I suggest we avoid duplication if possible. It is a little difficult to find a perfect structure for this wiki, but it will be orders of magnitude better than the maze we now have (where it is easy to get lost). If we have a 3-level structure, and if the index is always present at the left of the screen, then it is almost impossible to get lost. For example, if someone looks for Homerun under "NAS", it takes only two clicks to either find it, or discover that it is not there. So they look at the index and know that it is probably under "Media->TV Capture". We would no longer have the hidden doors, secret passages, and one-way corridors that we currently have in the wiki.

I'm not sure exactly what you mean by hacks, or how many of them we have (an example might help me). Maybe hacks belong in the forum. Maybe they belong in the wiki mixed in with everything else, but are identified as hacks by font, page color, or some such.

Maybe automation and security should be lumped to begin with. If the category gets too big, we can split them out. But you're probably correct - not too many articles on security right now.