Topics

16

Users / How to get MythTV to use software RAID

« on: September 08, 2008, 06:13:58 pm »

I had a lot of extra space on my system drive, so I have been using it to store all of my mythTV recordings. Now that the drive is nearing full capacity, and that I have a ton of space available on my software RAID - I would like for mythTV to start using my software Raid instead of my system drive.

Is there an easy way to do this? If I remember right, I had the choice when I first installed the capture card. I'm just not sure how to change it now after the fact...

thanks

17

Developers / Brainstorming ideas for persistance across reloads/reboots

« on: August 18, 2008, 06:10:18 pm »

While working on Toggle Power/Input bugs, it really bacame apparent that we really need a way for individual modules to have persistant information across reloads of the DCE router. Toggle-command devices aren't the only thing that could benefit either - Lighting Plugin would benefit greatly as well especially for light switches that can't be polled for their status.

The only thing that makes sense to me is to have this functionallity locally coded for each module/plugin. This way, if persistant data is needed, you only have to add a bit of code to do it. If it is not needed, nothing needs changed.

Some Ideas that I had were:
1) Addition of a "Safe Reload" command. When this command is received, it sends out a "Safe Reload Received" event that each module/plugin could receive, and save whatever data they need. After a set amount of time, a normal relaod is carried out. Then, for example, after the reload is finished and the module is run, instead of initializing everything to 0, it can check for the existance of persistant data, and if it is less than 10 minutes old, use it - otherwize initialize to 0 as it does now. (this is just an example)

OR

2) Instead of creating and implementing a new "Safe Reload" command, just modify the handling of the current reload to do as above: emit an event so other modules can clean up, then carry on with the reload. (Though the idea of a separate Safe Reload command appeals to me more.

3) Of course, it can be hacked in per module, saving values to a file when they change. But this is both messy and causes unnecessary disk usage.

4) A new PersistantData plugin where other plugins can register data to keep a local copy of, and restore them from the PersistantData plugin after reload (this would require that the PersistantData plugin be left alone during reload)


Anyone have some other suggestions or opinions we can kick around?

18

Users / Shares all disappeared (CIFS)

« on: August 18, 2008, 12:41:20 am »

Yesterday my shares all disappeared. I have rebooted a few time since, and no computers on my network can see any windows shares. NFS shares are still there and available however. Looking at syslog, I have a ton of CIFS errors:

Code: [Select]

CIFS VFS: Error connecting to IPv4 socket. Aborting operation
Aug 17 15:59:49 dcerouter kernel: [  158.196000]  CIFS VFS: cifs_mount failed w/return code = -111
Aug 17 15:59:49 dcerouter automount[23568]: >> mount error 111 = Connection refused

any tips?

19

Users / MythTV recordings played through LinuxMCE don't scale to screen (Solved)

« on: August 15, 2008, 03:28:50 pm »

I'm now using mythtv full-go, recording 14 hours worth of material per day. The only problem I have not figured out so far is how to get the video to scale to the screen when played through LMCE via the Videos datagrid.

When played through LMCE, the recordings are played in a small box about 2/3rd the size of my screen (in all directions). Even though my screen is a widescreen, and the recorded material as 4:3, it should at least scale so that the video is the full height of the screen. CUrrently, I have to go to Zoom&Aspect->Zoom 120% to fill the screen vertically. It is a real pain to do this each and every time I watch something recorded.

Does anyone else have this problem? Is there a setting i'm missing?

I'll try to get a picture later tonight when I get home.

20

Feature requests & roadmap / MythTv Filenaming convention change...

« on: August 14, 2008, 02:43:43 pm »

I have already opened a Mantis ticked for this feature request, but wanted to open it up for some discussion.

Currently, recording created with MythTV have a very cryptic filename consisting of the channelID (not necessarily the Channel Number), creation date, etc. It makes it a mess to try to edit attributes via Media Files Sync, or try to find any particular recording at all without using a MythTV frontend. This makes managing a large recording library in LMCE extremely difficult.

The prolem is, this is just how MythTV stores recordings, and there is no user-defined way of changing it. Manually renaming the files is not a great option either, as the MythTV database tables will be out of sync, making the MythTV frontend not work for these files.

So what are some options?
1) Add another User Job that executes after recording that renames the file, then also renames the entries in the database. The problem here is that LMCE move/rename/delete functionality would have to take into consideration MythTV's database.

2) Creat another directory full of Symbolic Links to the original files, but with human-readable names. This has the positive side that MythTV frontends will work as normal with no changes, but then you have the problem of keeping the symbolic links in sync with the actual files, considering they can be moved/deleted/renamed by both MytTV and LMCE. It would almost make sense to have the sym links created right in the appropriate /home/data/video directory used by LMCE, and have the symlinks added to the LMCE database instead of the original MythTV files. Again, the big problem here is sorting out the mess of keeping the symLinks in sync with the files knowing that there are 3 ways they could change (from MythTV, from LMCE, and from the OS level)

3) New Feature/Sourcecode change to MythTV that allows users to specify their recording filename format. However, this should be done on the MythTV end, and not applied as a patch as it would turn into a headache keeping up with MythTV releases. The good is that it would fix the problem, the bad is that it would need implemented of course.


Anyone else have some input on this?

21

Users / best solution for mythfilldatabase.sh?

« on: August 13, 2008, 04:28:29 am »

I've been really starting to use mythtv to its fullest. We are really enjoying it, but - it is a known problem that the program guide data does not stay populated. I have looked at mythfilldatabase.sh and MythTVDailyFillDB.sh. I have been manually running mythfilldatabase.sh every day to keep my guide data current, but I am noticing several problems.

- it takes anywhere from 6-8 hours for mythfilldatabase to run. During this time Top shows CPU usage from 80%-90% on mysqld (due to the number of database operations). My entire LMCE setup lags terribly during this time.

- it appears to download and resync the entire 14 days worth of guide data (over 600 channels worth at that) each time I run it. I would have figured it would only download and add to the database only the days it needs to be 14 days ahead.

So - while I'm enjoying the mythtv experience, I really wish there was a better way than manually running a script every day that takes up 6-8 hours while lagging my entire system. Also to note, the system is of very capable specs (BE2400 CPU, 4 gig RAM) so why its bogging me down so bad is a mystery to me.

Is there a more elegant solution? This is just the beginning of my mythtv experience, so I'm a little ignorant on the subject. Any help would be appreciated.

22

Users / Mythtv Autotranscode from mythweb? (Solved)

« on: August 13, 2008, 04:17:35 am »

I've been using mythweb for my scheduling. I always check the boxes to Auto-flag commercials and auto-transcode.
It appears that the commercials get flagged, but auto-transcode never runs. This is confirmed by watching the Job Queue  on the status page.

What can I do to get auto-transcode working correctly? I would really like the commercials to be skipped, along with having smaller file sizes for my recording.

thanks

23

Users / Can anyone view listings in MythWeb? (Solved)

« on: August 11, 2008, 11:59:16 am »

I'm looking for an easier way to schedule my recordings so I took a look at mythWeb this morning. Most links seem to work, however trying to view the listing always bombs out on me:

Code: [Select]

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 35 bytes) in /usr/share/mythtv/mythweb/includes/programs.php on line 420

Is anyone else having this problem? Can you schedule recording directly from the listings (if it were working for me)?

24

Users / Motherboard recomendations/advice

« on: August 06, 2008, 02:52:16 pm »

I've decided to get a new motherboard, as my M2NPV-VM has been giving me fits with network drops, raid crashes, lockups, etc. I have spend a lot of time looking through the wiki and I also wanted to get experiences and opinions on some of the boards I'm looking at - as well as suggestions of other boards.

To keep things as cheap as possible, the folowing criteria is what I'm aiming for:
-As much as possible on-board both to keep cost down and keep expansion slots free (onboard video, audio,lan,etc)
-I would like 6 SATA ports. In the past, 4 ports has limited my on-board software RAID to about 2GB as Raid5. I would like to grow this, as well as have a hot spare.
-Many PCI slots. I would like more than 2 PCI slots - its just so limiting
-Socket AM2 so I can re-use my BE-2400 processor
-ATX and MicroATX form factors are fine - i have plenty of room

Here are the boards I am looking at:
Asus M2N-SLI Deluxe
Pros:

• 6 SATA Ports
• 3 PCI slots
• Dual on-board gigabit
• Digital Audio Out
• Has been reported as stable with LinuxMCE

Cons:

• No onboard video (though this is somewhat negated by the dual gigabit lan and plenty of expansion slots)
• Reports of ASCPI issues in the wiki (but others report not having the issues)
• Asus product (after my M2NPV-VM experience, i'm not sure if I want another ASUS product)

Abit A-N78HD
Pros:

• 6 SATA ports
• Onboard Gigabit Lan
• Onboard Geforce 8200[\li]
  

Cons:

• Untested with LinuxMCE
• 2 PCI Slots
• Appears to have no optical audio header
• Unsure about onboard Geforce 8200 with LMCE

Abit AN78GS
Pros:

• 6 SATA Ports
• 3 PCI SLots
• Onboard Geforce 8200
• Onboard gigabit lan

Cons:

• Untested with LMCE
• Unsure if it has optical audio header. I see it has a coax though...
• Unsure about stability/performance of onboard geforce 8200 with LMCE

Also - As I've never changed out a motherboard under LMCE - will it require a full reinstall, our should the hardware changes detect automatically?

Thanks for any help tips and advice

25

Users / Horrible Network instability problems

« on: August 06, 2008, 12:06:43 pm »

We have been discussing this problem along with my RAID problem here: http://forum.linuxmce.org/index.php?topic=5892.0. Both problems have become so severe that I decided to separate my network/stability issues into this thread.

For a few weeks now, it appeared that my core was locking up on a nightly basis, without fail. (couldn't SSH in, network would be down, etc..) After more poking around, the core was not actually locking up, but killing the network on Eth:0 (onboard NIC of my Asus M2nPV-VM, a well tested and supported MB) every single night.

Please note that I have been using this same setup for over 6 months with absolutely no problems!

The only changes have been the addition of a new switch (Netgear GS524) and Access Point (Netgear WG302). I've recently spoke with Netgear Tech Support to ensure it is all set up properly.

Here are some different entries from syslog - not sure if any of them are related to my problem:

Code: [Select]

Aug  6 05:39:20 dcerouter kernel: [  690.972000] rtc: lost 27 interrupts
Aug  6 05:39:22 dcerouter kernel: [  693.024000] rtc: lost 28 interrupts
Aug  6 05:39:24 dcerouter kernel: [  695.076000] rtc: lost 28 interrupts
Aug  6 05:39:30 dcerouter kernel: [  701.232000] rtc: lost 28 interrupts
Aug  6 05:39:32 dcerouter kernel: [  703.288000] rtc: lost 27 interrupts
I get the above all the time in my syslog. Not sure if it has always been like this or not, since these problems started before the 6 days worth of archived logs kept on the core.

Code: [Select]

Aug  6 05:40:42 dcerouter kernel: [  772.760000] eth0: too many iterations (6) in nv_nic_irq.
Aug  6 05:40:43 dcerouter kernel: [  773.752000] eth0: too many iterations (6) in nv_nic_irq.
Aug  6 05:40:44 dcerouter kernel: [  774.752000] eth0: too many iterations (6) in nv_nic_irq.
Aug  6 05:40:46 dcerouter kernel: [  776.756000] eth0: too many iterations (6) in nv_nic_irq.
I see the above pretty often in syslog as well. Not sure exactly what it means though...

Code: [Select]

Aug  6 04:00:15 dcerouter kernel: [81443.716000] printk: 1 messages suppressed.
Aug  6 04:00:15 dcerouter kernel: [81443.716000] rtc: lost 27 interrupts
Aug  6 04:00:19 dcerouter kernel: [81447.820000] printk: 1 messages suppressed.
Aug  6 04:00:19 dcerouter kernel: [81447.820000] rtc: lost 28 interrupts
Aug  6 04:00:23 dcerouter kernel: [81451.924000] printk: 1 messages suppressed.
Aug  6 04:00:23 dcerouter kernel: [81451.924000] rtc: lost 28 interrupts
Aug  6 04:00:23 dcerouter kernel: [81452.000000] NETDEV WATCHDOG: eth0: transmit timed out
Aug  6 04:00:23 dcerouter kernel: [81452.000000] eth0: Got tx_timeout. irq: 00000036
Aug  6 04:00:23 dcerouter kernel: [81452.000000] eth0: Ring at 1fe0e000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] eth0: Dumping tx registers
Aug  6 04:00:23 dcerouter kernel: [81452.000000]   0: 00000036 000000ff 00000003 00df03ca 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  20: 00000000 f0000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  40: 0420e20e 0000a455 00002e20 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  60: 00000000 00000000 00000000 0000ffff 0000ffff 0000ffff 0000ffff 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  80: 003b0f3c 00000001 00000000 007f0028 0000061c 00000001 00200000 00007fc9
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  a0: 0014050f 00000016 45f31800 00002e3b 00000001 00000000 8000cccd 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  c0: 10000002 00000001 00000001 00000001 00000001 00000001 00000001 00000001
Aug  6 04:00:23 dcerouter kernel: [81452.000000]  e0: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 100: 1fe0e800 1fe0e000 007f00ff 00008000 00010032 00000000 00000017 1fe0ecd0
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 120: 1fe0e050 1c104840 a000ffeb 00000000 00000000 1fe0ecdc 1fe0e05c 0fe08000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 140: 00304120 80c02200 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 180: 00000016 00000008 0194796d 00008103 0000002a 00007800 0194796d 0000f903
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 1a0: 00000016 00000008 0194796d 00008103 0000002a 00007800 0194796d 0000f903
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 1c0: 00000016 00000008 0194796d 00008103 0000002a 00007800 0194796d 0000f903
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 1e0: 00000016 00000008 0194796d 00008103 0000002a 00007800 0194796d 0000f903
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 200: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 220: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 240: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 260: 00000000 00000000 fe020001 00000100 00000000 00000000 fe020001 00000100
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 280: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 2a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 2c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 2e0: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 300: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 320: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 340: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 360: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 380: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 3a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 3c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 3e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 400: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 420: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 440: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 460: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 480: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 4a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 4c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 4e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 500: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 520: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 540: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 560: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 580: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 5a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 5c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 5e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 600: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug  6 04:00:23 dcerouter kernel: [81452.000000] eth0: Dumping tx ring
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 000: 00000000 10394002 20000040 // 00000000 10394202 20000040 // 00000000 10394402 20000040 // 00000000 10394602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 004: 00000000 10394802 20000040 // 00000000 10394a02 20000040 // 00000000 10394c02 20000040 // 00000000 10394e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 008: 00000000 18e68002 20000040 // 00000000 18e68202 20000040 // 00000000 18e68402 20000040 // 00000000 18e68602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 00c: 00000000 18e68802 20000040 // 00000000 18e68a02 20000040 // 00000000 18e68c02 20000040 // 00000000 18e68e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 010: 00000000 19473002 20000040 // 00000000 19473202 20000040 // 00000000 19473402 20000040 // 00000000 19473602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 014: 00000000 19473802 20000040 // 00000000 19473a02 20000040 // 00000000 19473c02 20000040 // 00000000 19473e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 018: 00000000 19472002 20000040 // 00000000 19472202 20000040 // 00000000 19472402 20000040 // 00000000 19472602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 01c: 00000000 19472802 20000040 // 00000000 19472a02 20000040 // 00000000 19472c02 20000040 // 00000000 19472e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 020: 00000000 19471002 20000040 // 00000000 19471202 20000040 // 00000000 19471402 20000040 // 00000000 19471602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 024: 00000000 19471802 20000040 // 00000000 19471a02 20000040 // 00000000 19471c02 20000040 // 00000000 19471e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 028: 00000000 19470002 20000040 // 00000000 19470202 20000040 // 00000000 19470402 20000040 // 00000000 19470602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 02c: 00000000 19470802 20000040 // 00000000 19470a02 20000040 // 00000000 19470c02 20000040 // 00000000 19470e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 030: 00000000 1c107002 20000040 // 00000000 1c107202 20000040 // 00000000 1c107402 20000040 // 00000000 1c107602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 034: 00000000 1c107802 20000040 // 00000000 1c107a02 20000040 // 00000000 1c107c02 20000040 // 00000000 1c107e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 038: 00000000 1c106002 20000040 // 00000000 1c106202 20000040 // 00000000 1c106402 20000040 // 00000000 1c106602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 03c: 00000000 1c106802 20000040 // 00000000 1c106a02 20000040 // 00000000 1c106c02 20000040 // 00000000 1c106e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 040: 00000000 1c105002 20000040 // 00000000 1c105202 20000040 // 00000000 1c105402 20000040 // 00000000 1c105602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 044: 00000000 1c105802 20000040 // 00000000 1c105a02 20000040 // 00000000 1c105c02 20000040 // 00000000 1c105e02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 048: 00000000 1c104002 20000040 // 00000000 1c104202 20000040 // 00000000 1c104402 20000040 // 00000000 1c104602 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 04c: 00000000 1c104802 20000040 // 00000000 20cfb002 20000040 // 00000000 20cfb202 20000040 // 00000000 20cfb402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 050: 00000000 20cfb602 20000040 // 00000000 20cfb802 20000040 // 00000000 20cfba02 20000040 // 00000000 20cfbc02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 054: 00000000 20cfbe02 20000040 // 00000000 0f50d002 20000040 // 00000000 0f50d202 20000040 // 00000000 0f50d402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 058: 00000000 0f50d602 20000040 // 00000000 0f50d802 20000040 // 00000000 0f50da02 20000040 // 00000000 0f50dc02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 05c: 00000000 0f50de02 20000040 // 00000000 0e454002 20000040 // 00000000 0e454202 20000040 // 00000000 0e454402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 060: 00000000 0e454602 20000040 // 00000000 0e454802 20000040 // 00000000 0e454a02 20000040 // 00000000 0e454c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 064: 00000000 0e454e02 20000040 // 00000000 1cd67002 20000040 // 00000000 1cd67202 20000040 // 00000000 1cd67402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 068: 00000000 1cd67602 20000040 // 00000000 1cd67802 20000040 // 00000000 1cd67a02 20000040 // 00000000 1cd67c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 06c: 00000000 1cd67e02 20000040 // 00000000 0d83f002 20000040 // 00000000 0d83f202 20000040 // 00000000 0d83f402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 070: 00000000 0d83f602 20000040 // 00000000 0d83f802 20000040 // 00000000 0d83fa02 20000040 // 00000000 0d83fc02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 074: 00000000 0d83fe02 20000040 // 00000000 105f0002 20000040 // 00000000 105f0202 20000040 // 00000000 105f0402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 078: 00000000 105f0602 20000040 // 00000000 105f0802 20000040 // 00000000 105f0a02 20000040 // 00000000 105f0c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 07c: 00000000 105f0e02 20000040 // 00000000 2740b002 20000040 // 00000000 2740b202 20000040 // 00000000 2740b402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 080: 00000000 2740b602 20000040 // 00000000 2740b802 20000040 // 00000000 2740ba02 20000040 // 00000000 2740bc02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 084: 00000000 2740be02 20000040 // 00000000 1bc58002 20000040 // 00000000 1bc58202 20000040 // 00000000 1bc58402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 088: 00000000 1bc58602 20000040 // 00000000 1bc58802 20000040 // 00000000 1bc58a02 20000040 // 00000000 1bc58c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 08c: 00000000 1bc58e02 20000040 // 00000000 208e7002 20000040 // 00000000 208e7202 20000040 // 00000000 208e7402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 090: 00000000 208e7602 20000040 // 00000000 208e7802 20000040 // 00000000 208e7a02 20000040 // 00000000 208e7c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 094: 00000000 208e7e02 20000040 // 00000000 36193002 20000040 // 00000000 36193202 20000040 // 00000000 36193402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 098: 00000000 36193602 20000040 // 00000000 36193802 20000040 // 00000000 36193a02 20000040 // 00000000 36193c02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 09c: 00000000 36193e02 20000040 // 00000000 113dc002 20000040 // 00000000 113dc202 20000040 // 00000000 113dc402 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 0a0: 00000000 113dc602 20000040 // 00000000 113dc802 20000040 // 00000000 113dca02 20000040 // 00000000 113dcc02 20000040
Aug  6 04:00:23 dcerouter kernel: [81452.000000] 0a4: 00000000 113dce02 20000040 // 00000000 113dd002 20000040 // 00000000 113dd202 20000040 // 00000000 113dd402 20000040
...
...
truncated to stay under the 20000 character post limit

I have a slew (meaning thousands) of these prior to my reboot this morning. The first one appeared in the log at 0358 in the morning, and they continued at least a few times a minute for the remainder of the night until my reboot.

Ok, so what now? I can't fathom why out of nowhere I am having these problems after 6 months of near perfect stability?

26

Users / Any RAID gurus in here? (more RAID problems)

« on: July 30, 2008, 04:12:44 am »

Well, i'm back to having raid troubles again. (this is the same thing that happened that caused me to lose all of my data last time)

I did some simple checks with mdadm - and it agrees that the status of one of the drives is Removed... (what is strange is that the drive is good - it said this last time, and it was fine on a fresh install for over a month)

Code: [Select]

linuxmce@dcerouter:~$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Sat Jun 14 09:30:50 2008
     Raid Level : raid5
     Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
   Raid Devices : 3
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Jul 29 22:04:34 2008
          State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : ef05e3dd:c2ec8d78:bd9f1658:0a1d2015 (local to host dcerouter)
         Events : 0.140014

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd


lookin in the web admin, sdb,sdc,and sdd are the 3 drives for the array. In the admin, /dev/sdb is show as "Spare", "Removed"

What should my next step be? I don't want to jump the gun again and lose all my data again in the process...

27

Developers / Testers for Playlist Export functionality (.m3u, .pls)

« on: July 17, 2008, 11:33:19 pm »

I have just committed revision #21207 which includes playlist export. Playlists can now be exported to M3U (*.m3u), Extended M3U(*.m3u) and Shoutcast Playlist (*.pls) formats. You are also able to select whether to only export Music Files, Music and Video Files, or All Files (Full Backup).
I have tested it on every linux media player I could get my hands on that supports media on network shares, with positive results. I would be interested in hearing how the generated playlists do on Windows and Mac platforms.

If anyone is willing to do some testing, here are the instructions to get it working...
1) Have a development environment installed
2) run an svn update on the charon-merge branch (should get you to svn revision 21207 or higher)
3) Copy the following files from ~/charon-merge/web/pluto-admin/ to /var/www/pluto-admin/:
      index.php
      languages/en/exportPlaylist.lang.php
      operations/mediaBrowser/exportPlaylist.php
      operations/mediaBrowser/playlists.php
      operations/mediaBrowser/editPlaylist.php
      operations/mediaBrowser/images/*

Export options are available from the main playlist page, and the edit playlist page.

Once I can confirm that generated playlist work as expected in most cases, I will finish the playlist import functionality. Of course, if you notice any bugs or anything out of place, please post here so I can fix it.

28

Developers / sqlCVS web admin is now fixed!

« on: July 12, 2008, 04:15:56 pm »

I'm finished with updates to the sqlCVS web admin. The sqlCVS Diff, sqlCVS Update and sqlCVS Checkin pages have all been reworked, and bugs fixed. Checkboxes are now considered as they should be, and a sqlCVS maskfile is properly generated. Also, a new area to enter comments (relation to Mantis ticket numbers, etc) to be sent with checkins.
I have spent several hours testing it with no problems.

(One remaining bug, which I haven't looked into yet, is when you switch the database to the mythTV database, it generates an SQL error. It looks like a permissions problem, but I haven't looked at it yet)

I just committed the changes, so if anyone wants to start using it, run an svn update, then replace the following files in /var/www/pluto-admin with the updated files in ~/charon-merge/web/pluto-admin:
/operations/sqlCVS/sqlcvs_diff.php
/operations/sqlCVS/sqlcvs_checkin.php
/operations/sqlCVS/sqlcvs_update.php
/languages/en/sqlcvs.lang.php

29

Developers / I believe I have found a bug in the sqlCVS binary

« on: July 10, 2008, 01:24:55 pm »

When an qdlCVS diff is run, a status is returned against database entries (Change:NEW, Change:MOD, etc..) Recently, while investigating an unrelated bug, I noticed that I have never seen Change:DEL in sqlCVS. Looking through the source, there indeed should be a Change:DEL status for entries that have been deleted in the local working copy of the database that exist in the master database.

To further test this, I purposely deleted some entries from my local database to test this out..  I chose something that I would likely never need - so I looked at InfraredGroup_Commands for FK_InfraredGroup #5956 (just listed as "qqq").
In InfraredGroup_Commands, I deleted the entry PK_InfraredGroup_Command 166388. Running sqlCVS agains all IR database tables, I was presented with some Change:NEW for a lot of my new additions for my own IR devices, a Change:MOD for one that I had modified, but no Change:DEL!

Any easy way to test this is to do an sqlCVS diff from the web admin. sqlCVS outputs a file to /tmp that is used for generating the web page. If you look in /tmp, the temporary files of the sqlCVS output will be apparent to you. You can see that Change:DEL is nowhere to be found - even though I had just deleted an entry tracked by sqlCVS on my local database copy. (i checked the temp file just in case there was a bug displaying DEL information in the web admin page - but the output on the web admin page matches the sqlCVS generated file.)

I only spent about half an hour on this before coming to work this morning, but wanted to hear if anyone else could reproduce my findings while I'm at work today so I can start digging into why Change:DEL is not being flagged for locally deleted files.

30

Users / Can somebody create a playlist for me? (playlist editor- testing m3u support)

« on: July 02, 2008, 04:12:14 pm »

Can somebody use a playlist creation utility to create a playlist (m3u) of a few songs stored on the core from a remote computer over samba, using full paths and email it to me? can you also attach a text file with a list of the full paths of the media files on the core?

I have *some* preliminary M3U inport/export functionallity going on in the new playlist editor for the web admin, but I need to test a few things (mainly converting full samba paths into internal LMCE paths)..

If you can supply this, please email it to me at jondecker76 at windstream dot com

Also, to clear up any confusion, playlists will be handled the same way by LMCE. This is just adding functionallity to save your LMCE playlist as an extended .m3u playlist for backup purposes, and to have a "synchronized" playlist on your computers. Similarly, playlist import will add files (if present on the core) from a .m3u playlist to a LMCE Playlist (at the beginning, at the current selection, or at the end).