jetkins

Well it appears this may not be an issue with your image - I'm now having the same problem with another pyTivo installation as well. I'll update here if/when I find a solution.

Hey there. first of all, thanks for putting the pyTivo image together. I have it installed on my Synology NAS and it's working great... with a couple of exceptions: I can pull from the NAS to the TiVo (a Bolte+ if that makes any difference), and the files transfer fine, but when I try to push from pyTivo to the Tivo, I get an error: ERROR:pyTivo.video.video:<error><code>internalError</code><debug>java.lang.InternalError: Deprecated Operation: bodyOfferModify at com.tivo.trio.mind.cds.BodyOfferModify.doItWithInitializedDb(BodyOfferModify.java:41) at com.tivo.trio.mind.core.ReadWriteOperation$1.call(ReadWriteOperation.java:65) at com.tivo.trio.mind.core.Job$Action.internalRun(Job.java:314) at com.tivo.trio.mind.core.Job.retry(Job.java:94) at com.tivo.trio.mind.core.ReadWriteOperation.doIt(ReadWriteOperation.java:74) at com.tivo.trio.mind.core.MindSession.internalDoIt(MindSession.java:540) at com.tivo.trio.mind.core.MindSession.doItWithMindRequest(MindSession.java:426) at com.tivo.trio.mind.toplevel.Mind.doItWithMindRequest(Mind.java:253) at com.tivo.trio.tomcatmind.TomcatMind.callMind(TomcatMind.java:1210) at com.tivo.trio.tomcatmind.TomcatMind.checkAndDoRequest(TomcatMind.java:1180) at com.tivo.trio.tomcatmind.TomcatMind.doIt2(TomcatMind.java:894) at com.tivo.trio.tomcatmind.TomcatMind.doIt(TomcatMind.java:740) at com.tivo.trio.tomcatmind.TomcatMind.doPost(TomcatMind.java:711) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) </debug><text>Deprecated Operation: bodyOfferModify</text></error> This error appears to be a result of specifying incorrect TiVo account and password details in the General Settings, but I have checked and double-checked that the information is correct. Perhaps this is a bug that has been addressed in a later version of PyTivo, and your image just needs a refresh? The pyTivo process runs under UID 99 / GID 100. On a Synology, this means that I have to grant group Users (basically everybody) read/write access to my Media share in order for PyTivo to work. Would it be possible (pleeease?) to externalize the GID/UID as Environment Variables so that the user could override them if necessary to better suit the hosting environment?

Bad news, I'm afraid. The EX4350 detects the drive and exports it as JBOD, but unRAID doesn't detect the controller or the drive(s) attached to it. I guess it needs a driver, and while Promise make various flavor of driver - including open source - available on their web site, I don't have the time or expertise to futz with porting it to unRAID. I'll hang on to the card in case someone else with more time, skill, and enthusiasm takes up the challenge, but for now it's a non-starter. [EDIT] I found this thread which talks about the same issue, and comes to the same conclusion.

Drive temp 25C?!? Are you in Alaska, or do you have so many fans that hearing protection is required? 25C is the ambient temperature in my "server room."

No, but I just picked up an EX4350 (4-port) which I'll be trialling once my 3TB pre-clear completes overnight. I'll let y'all know how it goes.

Ah, that could it. According to the VMware KB: Well, that's a PITA. Fortunately the ESXi host is the only thing using NFS on my LAN, so it's not really that big of an exposure in my situation, but I could see how it would render unRAID unusable in other environments with stricter requirements.

Further info: I checked the system log to compare what unRAID is doing differently between public and private configurations: With sharing set to Private: With sharing set to Public: Now unless my eyes (and diff) are lying to me, the only difference is in the substitution of the desired IP address for the * wildcard. This should work, so I believe this should be categorized as a bug.

I just migrated from 4.7 to 5.0-rc16c, and I'm having trouble getting my NFS exports to work the way they used to. In particular, I have one share that is used as a VMware datastore, which I want restricted to one IP address (my ESXi server) with read/write access. Under 4.7, I used "192.168.0.3(rw)", but when I set security to Private and use that same rule under 5.0, ESXi can't access the export. I found this thread which suggests a more convoluted rule, but even that doesn't work for me. The only ways I have been able to get working, are to set it to Secure, which allows read-only access to everyone, or Public, which allows everyone read-write. Neither is really an acceptable solution. Has anyone got IP-restricted NFS sharing working under 5.0? This seems like such a fairly fundamental limitation that I'm surprised there hasn't been more discussion of it; perhaps there are only a handful of us who actually use NFS?

That sounds like it exactly. I'll run a couple of regular parity checks - one to fix and one to verify - before moving on. Thanks, Gary.

I recently had a drive die, replaced it, and rebuilt the array. Now, not 24 hours later, I'm running a non-correcting parity check as a sanity/safety check before migrating to v5, but I'm getting four parity errors. These occur very early in the scan - literally within seconds of starting it - which makes me suspect the affected areas may be in the system data not my user data. I'm also puzzled where they came from, as the array was reconstructed from the parity just only yesterday. Is there a how-to that can help me identify the affected files given the addresses reported in the log? If I determine that the affected file(s) is corrupt, how does one force a rebuild of the data from the parity instead of the default vice versa? Aug 26 13:02:59 Tower kernel: md: parity incorrect: 18144 Aug 26 13:02:59 Tower kernel: md: parity incorrect: 18152 Aug 26 13:02:59 Tower kernel: md: parity incorrect: 18168 Aug 26 13:02:59 Tower kernel: md: parity incorrect: 18176

Well, I discovered I had a spare identical 1.5TB Seagate drive, so I swapped it in for the dead drive but unRAID refused to use it because it was reporting a smaller capacity than the rest of them. A little digging found the forum article about HPA, and by using the referenced hdparm -N method, I was able to reset it to full capacity. The array is now rebuilding, and I'll look at migrating to unRAID v5 another day. Thanks again for your help.

Well, I did as instructed, but after powering back up, I see Disk status Model / Serial No. Temperature Size Free Reads Writes Errors parity Missing - - - - - - ST31500341AS_9VS32171 1,465,138,552 disk1 ST31500341AS_9VS32171 38°C 1,465,138,552 - - - - disk2 ST31500541AS_6XW01X0V 33°C 1,465,138,552 - - - - disk3 ST31500541AS_9XW0DVCD 35°C 1,465,138,552 - - - - cache ST3160827AS_4LJ1JF63 34°C 156,290,872 - - - - Command area Stopped. Invalid configuration. Too many wrong and/or missing disks! The Parity drive has a red dot, Disk 1 has a blue dot, and the Start button is grayed out. If I go to the Devices screen, I see it has detected the new 3TB WD drive and has it selected as the parity drive, so it seems that it kinda knows what I want to do but hasn't automatically implemented the reconstruction process described in the manual. I'm open to suggestions where to go from here. I guess I need to somehow commit the new configuration?

OK, never mind, I read the link you cited. Thanks, I'll give it a try tomorrow. Fingers crossed.

With one drive failed, the parity drive is the only thing providing the data that used to be on that drive. How can I replace the parity drive without losing data?

I have four 1.5TB drives in my array, and one has just thrown a bunch of I/O errors and gone DSBL. I'm going to shut it down and check the physical connections, etc, but assuming it's dead, can I replace it with a 2TB drive, i.e. larger than the current parity drive? I want to restore redundancy ASAP, and I can't find any 1.5's available locally.

Turns out the timing was purely coincidental. The same messages appeared another couple of times over the next few days, and I eventually remembered the unMenu includes a Dupe Files feature which identified the culprits. After deleting the older duplicates, the problem has gone away.

Among my shares is one that I nfs mount to my VMWare ESXi server. Last night VMWare reported problems and froze the two VM's that use that datastore, and when I looked in the unRAID log for that timeframe I found the following: Apr 22 03:56:44 Tower shfs0: duplicate object: /mnt/disk3/ESX_Datastore/Myriad/Myriad-aux.xml Apr 22 03:56:44 Tower shfs0: duplicate object: /mnt/disk3/ESX_Datastore/Myriad/Myriad-aux.xml Apr 22 03:56:46 Tower shfs0: duplicate object: /mnt/disk3/ESX_Datastore/Blackbox/Blackbox.nvram Apr 22 03:56:46 Tower shfs0: duplicate object: /mnt/disk3/ESX_Datastore/Blackbox/Blackbox.nvram I have seen these sort of messages before, but only when the mover was moving the named files off the cache drive. This share has caching disabled, so it's probably coincidental that this happened while the nightly mover process was moving stuff on the shares that are cached, but it does seem strange. Any thoughts or suggestions?

Yes, you read my original post correctly, I'm seeing many dozens of iterations of basically the same messages. I've attached the complete warning email below. msg407412.txt

root@Tower:~# ls --time-style='+%Y-%m-%d %I:%M%p' /dev/disk/by-id/* -Hl | grep -v plugdev | grep -v "by-id/usb" | grep -v '\-part[1-9]$' | awk '{print $9}' /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 /dev/disk/by-id/ata-ST31500541AS_6XW01X0V /dev/disk/by-id/ata-ST31500541AS_9XW0DVCD /dev/disk/by-id/ata-ST3160827AS_4LJ1JF63 /dev/disk/by-id/scsi-SATA_ST31500341AS_9VS1NC4L /dev/disk/by-id/scsi-SATA_ST31500341AS_9VS1RW26 /dev/disk/by-id/scsi-SATA_ST31500541AS_6XW01X0V /dev/disk/by-id/scsi-SATA_ST31500541AS_9XW0DVCD /dev/disk/by-id/scsi-SATA_ST3160827AS_4LJ1JF63 root@Tower:~# Exactly "35" and "38" for warning and shutdown respectively. Would I be correct in surmising that the fact that each drive is appearing twice - once as "ata-..." and once as "scsi-SATA_..." is confusing things?

I've just upgraded to unMenu 1.3 and installed unraid-overtemp-shutdown. I've been testing overtemp by specifying thresholds below normal operating temperature, and while the warning email and automatic shutdown processes both work fine, the generated emails are excessivly verbose. Where I would expect one status line for each drive, instead it seems to be iterating the same information almost endlessly - over 2000 lines and 74k of text for six drives! Here's the first couple of iterations. Anyone have any idea how to rein it in? Subject:EMERGENCY unRaid Overtemp Shutdown Warning Date: Wed Nov 3 13:45:03 CDT 2010 Server Name: Tower Server IP: 192.168.0.8 ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . disk /dev/disk/by-id/ata-ST31500541AS_9XW0DVCD temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . . disk /dev/disk/by-id/ata-ST3160827AS_4LJ1JF63 temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . disk /dev/disk/by-id/ata-ST31500541AS_9XW0DVCD temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . . . ** disk /dev/disk/by-id/scsi-SATA_ST31500341AS_9VS1NC4L temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . disk /dev/disk/by-id/ata-ST31500541AS_9XW0DVCD temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . . disk /dev/disk/by-id/ata-ST3160827AS_4LJ1JF63 temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . disk /dev/disk/by-id/ata-ST31500541AS_9XW0DVCD temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . disk /dev/disk/by-id/ata-ST31500541AS_6XW01X0V temperature is 34C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1RW26 temperature is 40C ** disk /dev/disk/by-id/ata-ST31500341AS_9VS1NC4L temperature is 40C . . . . . . ** disk /dev/disk/by-id/scsi-SATA_ST31500341AS_9VS1RW26 temperature is 40C

Many (most/all?) modern drives support querying of SMART parameters even when they're spun down. unRAID does not yet handle that possibility and will show * for the temperature of any spun-down drives, but if you install unMenu you can tell it (via directives in /boot/unmenu/myMain_local.conf) which of your drives support that function, and unMenu will show temps for them regardless of their state.

Thanks for replying, Rob. I bit the bullet and bought one, and it appears to be serving my purposes just perfectly. As you say, parity-protected writes may be a little slower - my Windows backup is running at around 13MB/s - but most of my write activity is done by background processes where ultimate throughput is less of an issue. Read performance is plenty fast enough for streaming HD video, which is all I ask. Add in the fact that it's running consistently 4-5 degrees C cooler than the equivalent 7200rpm drives, and costs a few dollars less even when not on special, and I'd say it's a no-brainer.

My unRAID server's motherboard SATA ports are only 150Mb/s SATA I. I have added two 2-port PCIe x1 300Mb/s SATA II adapters, and have one 1.5TB SATA II drive connected to each card. Until recently, my other two drives were older SATA I's, so I left them connected to the motherboard ports. However, I've now replaced one of the older drives with a new Seagate 5900rpm 1.5TB SATA II. It's currently connected to a third motherboard port, and the initial parity check after installation completed at 62.3 MB/sec. My dilemma is, would I be better off connecting the new drive to the second port on one of my PCIe cards or should I leave it on a separate motherboard channel but limited to SATA I speeds? Which would be the greater bottleneck: sharing the PCIe x1 bandwidth between two drives SATA II drives, or limiting one of them to SATA I on a motherboard port?

What's the general feeling towards the 5900's vs the 7200.11 'Cudas?

http://www.frys.com/product/6002438 I currently have 2x ST31500341AS; thinking of replacing one of my tiny drives with one of these. Any thoughts appreciated.