Okay, I understand…I will have to invest in a powered USB hub. So far though, no crashes and seems to be running pretty quick.
When I get home today, I’ll try to get that report and post the results. Thanks again
Please help!!! Broke OMV
-
I have a low voltage condition causing the CPU to throttle. I'm going to have to get a powered USB hub.
No.
This is NOT throttling but under-voltage and also 'frequency capping' (the three most left digits indicate this). Of course you should buy a good powered USB hub but you have to fix powering first (get the official RPi 3 PSU with fixed cable or if your current PSU has an USB type A receptacle get an appropriate Micro USB cable. But I already wrote all this stuff for a reason: New approach for Raspberry Pi OMV images -- check the Amazon link there)
-
-
When I got my first RPi I had an issue with the PSU. What a headache it caused. After I replaced the PSU all went well.
-
When I got my first RPi I had an issue with the PSU. What a headache it caused. After I replaced the PSU all went well.
But today there's no need to guess any more. On most recent OMV image for Raspberries /var/log/raspihealth.log is written on every shutdown. Every mod should know this since when RPi users report problems asking for this log file should be always the first step
-
-
Every mod should know this since when RPi users report problems asking for this log file should be always the first step
I thought recommending a different arm board was?
-
-
I thought recommending a different arm board was?
Well, if people are happy to run the slowest NAS in the world... why not?
BTW: Once software support for ROCK64 stabilizes and if the board is also available through reseller sites like Gearbest or when more RK3328 Gigabit Ethernet equipped boards are available for a competitive price then at least I will change my suggestion immediately and really recommend giving up on Raspberries and switching to something more powerful.
I now have Plex installed and am able to stream/transcode at 2mb/s 720p...
Plex server on these ARM devices uses a really old/outdated binary install made for an old Synology NAS. Streaming should always work and since movie bitrates are low anyway even such a slow board as a Raspberry should succeed.
Transcoding is different and using the CPU cores on an ARM device is stupid anyway since they are too slow. Since almost all ARM devices supported by OMV are made with smartphone, tablet or TV box SoCs (SoC -- System on Chip) they all have special video engines to be used for encoding (dealing with CSI camera input), decoding (displaying compressed video contents) and also transcoding (the combination of both).
The 'only' problem is that every SoC uses its own implementation and some stuff is simply not available when not used with proprietary solutions (the 'mythical' firmware on RPi or Android blobs on most other SoCs). But as soon as the special hardware engines can be used CPU limitations aren't an issue any more.
For example there exists an Emby version for ODROID-XU4 which uses hardware accelerated transcoding (no idea about Plex though) and with the ongoing work for ROCK64 (or other RK3328 based ARM boards later) we specifically have the Plex use case in mind (on RK3328 accessing the HW accelerated encoding, decoding and transcoding features from within Linux seems to be supported through gstreamer and ffmpeg).
We even currently only build armhf OMV images for ROCK64 since Plex installation is then not an issue (RK3328 is a 64-bit platform and usually one runs an arm64 userland on it but then installing Plex is a bit complicated especially when trying to do this with a few clicks in OMV UI). Let's wait and see, maybe in a few months we have Plex and Emby running on RK3328 with full HW acceleration.
-
The CPU was hovering between 75%-100% but it just worked
If you have a look at 'raspimon' output in parallel you might realize that unless you replace your PSU 'frequency capping' happens (forcing the CPU cores down to 600 MHz due prevent crashes/freezes due to under-voltage). If that happens then your RPi is performing only at 37.5%-50% of its CPU capabilities
Anyway: transcoding should work way better when the SoC's video engine can be used (even with more recent Intel CPUs that's the case --> QuickSync) but unfortunately there aren't that much ARM boards available where this actually works due to missing software support in Linux.
-
-
I looked at the raspimon output in parallel after connecting a powered USB hub and it no longer appears to be frequency capping?
Ohm's law as expected. Since now the HDD is powered by the USB hub overall consumption drawn from your RPi PSU is much lower and so are the voltage drops. Replacing the PSU (or the USB cable) is a good idea anyway.
With a good 20AWG rated Micro USB cable, a proper 5.2V/2A PSU and the config.txt tweak I am able to power an external 2.5 HDD successfully with both RPi 2 and 3. But with an average USB cable things start to fail as soon as there's some real and especially random IO load on the disk (eg. Plex starting to scan the media library)
-
-
Looking back through the tread;
Well, if people are happy to run the slowest NAS in the world... why not?
/--------------/Plex server on these ARM devices uses a really old/outdated binary install made for an old Synology NAS. Streaming should always work and since movie bitrates are low anyway even such a slow board as a Raspberry should succeed. /------------/
I've been using an R-PI as a backup file server (really a file repository) for a couple years. For this purpose, backup, it works fine (outside of SD-card issues and I have 3 cards to deal with that). However, beyond copying files with Rsync, R-PI's have limitations. I found that out through trial and error by installing plugins that I could easily back out of (using one of my 3 cloned SD cards). With the exception of lean and mean utilities, "value added plugins" (I'll call them) will swamp an R-PI. Plex, Emby, and others will bog an R-PI down so bad, if there are file shares, a 2nd user won't be able to access them.
Noting that the cost of hard drives in specific capacities are, more or less, fixed:
When adding up the costs of powered USB hubs, drive docks (this is how I got around the power issue in the beginning) and other misc. expenses, you're getting into striking range of the price of an entry level server for SOHO use. This becomes more apparent if / when you decide that you're going to need a 2nd disk.When balancing out the R-PI's cost savings against low performance, while factoring in the costs of the extra pieces and bits, I settled on this -> Server > (By watching Amazon for awhile, I got a slightly better deal at $225, with 8GB ECC, delivered.) I got an extra 4GB ECC on Ebay, used for $22.50 (It tested out fine.) So I ended up with a Server, 12GB ECC, that can run anything with good performance, with no limitations, that can easily house 3 disks, for well under $300.
Do I like the R-PI? Sure. Beyond the novelty, it's a decent file server backup that, complete with a 4TB disk, costs about $160. But if you want something beyond a basic file server.....
(Just my thoughts on the matter.)
-
Now since I am using EXT4 format, retrieving those pictures should the Pi crash may present a challenge on our Windows and Mac systems…
Booting a bootable Linux distro like systemrescuecd from usb stick would work well on those systems.
-
-
For this purpose, backup, it works fine
Well, my definition of 'working backup' is 'test restore until you can prove that a restore works reliably within an acceptable time frame'. With Raspberries, Fast Ethernet, a 4TB disk and an average 11MB/s read a full restore takes +100 hours. Sorry, that's way too long (speaking about restores only, I've no problem backing up super slow as long as it's guaranteed that restore works at top speed)
Unlike literally every other little ARM board out there you can also not just buy a cheap RTL8153 USB-Gigabit-Ethernet adapter since Raspberries have only a single USB2 connection to the outside all USB ports and Ethernet share. So even if you spend the additional 10 bucks to get such an USB Ethernet dongle it won't help much since your read speeds increase to approx 17 MB/s and we're still at ~65 hours for a full restore (that's more than two and a half days).
With those boring Banana Pis (or any other Allwinner A20 device) we get 50MB/s and end up with less than a whole day for a 4 TB restore. Here it starts to get acceptable. And with boards like ESPRESSOBin or ROCK64 (and soon some more boards based on the same RK3328 SoC) we're talking about real-world sequential read speeds exceeding 90 MB/s so a full 4TB restore takes less than 12 hours.
Just my 2 Cents since thinking about backup is wrong. Always think about restore first and what might happen. But to be honest: Even huge companies don't get it always. A former customer of mine had clustered and insanely expensive EMC backup/archive filers with full feature set (dedup and whatever) holding 80TB of data. And both cluster nodes only had a single Gigabit Ethernet NIC each. I let a test restore run which finished at an 'impressive' 65 MB/s which means full restore or desaster recovery would take 'only' 14 whole days.
Now since I am using EXT4 format, retrieving those pictures should the Pi crash may present a challenge on our Windows and Mac systems…
So it's time to download VirtualBox (free) and set up an OMV VM (also free) on Windows or macOS configured to directly access your USB disk with bridged networking.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!