I don't know anything about Lexar but I do know that SanDisk and Samsung manufacture their own cards where other brands may contract them out (usually to the lowest bidder) and put their label on them. Here's -> a comparison of Lexar to Samsung.
Here's info on -> Building OMV6
A utility that tests SD-cards in -> prerequistes. -> h2test_1.4.zip
(Note the minimum A1, Class 10 recommendation for the SD-card.)
And -> the SD-card test procedure.
Thank you very much for all the help.
I get your point. I don't want to be biased but i had a lot of SanDisk SD-cards and the bigger ones for my DSLR are okey
but the MicroSD-cards... Maybe i was just unlucky but to be honest, out of around 28 SD-cards mostly all from SanDisk and two from Samsung,
they quite dissapointed me a lot. Broke when i did not want them to breake and they almost never kept up their speed, never.
Maybe i was just unlucky but i don't trust them so much as before. To Samsung i cannot say so much for now. One faild 3 weeks after purchase and the other one performs good but i would have expected better latency, way better.
My lexar does perform good i think. They mention 90mb/s write peak and i get 85mb/s for 2h straight, so i would say it is okey.
I know Samsung and SanDisk do them their own but i cannot change my experience with them sadly. Maybe they suprise me in the
future. The Lexar cards i now own (two) were just a test but actually they suprised me positively. But who knows, everyone makes different experiences.
I don't want to praise or smash any manufacturer, just give me working cards that do what they should or promote then i am happy.
As for the testing, i will do that to the others too.
I yesterday tested my lexar one and h2test was good and i verified my installation with win32 diskmanager and also everything was fine.
I will further proceed, but this may take awhile.
If you have an O-scope or one of the more high end multi-meters, it might have an ripple function for testing switching supplies. (I tend to doubt you have one of these items.)
This is one of the problems with toy hardware. When I originally bought R-PI's, I bought two of them, with 2 power supplies and 2 SD-cards. That's the only way to have some certainly when using consumer hardware in a server role. It's helpful to be able swap components versus guessing at what might be wrong. And I've dealt with the headaches associated with buying generic SD-cards. (The generic's worked for awhile, then did bizarre things before they finally failed, early I might add. Lesson learned - never again.)
I still have Arm devices, but my OMV main server and first backup are on server grade hardware.
No i don't have one
but good to know how to test it.
Just a small note: I am still a student and sadly don't have thousands of euros laying around, otherwise you can be sure of
that my server would be based on server hardware
So please keep that in mind before ranting about RPis.
I already made a thread about a possible new server when i have the money (a few month ago). I can assure you that i would like to put the Pi aside but at the moment i cannot so i have to deal with that thing and have a small tiny server or none.
No bad blood, just a note.
Also note that the above could be coincidental. Hardware can, and will, fail over time. Nothing is perpetual especially if you're running the R-PI without an UPS or a surge suppressor.
Sure, maybe the day of the day has come for my Pi.
Of note, as mentioned before, Raspberry PI OS may change without notice. I ran into an issue with building OMV5 on R-PI OS Lite that (as I remember) was related to networking. They did something that appeared to be, well, foolish. Then, out of the blue, the issue disappeared in the next minor update. Stuff like that happens.
true. Happens.
That would be great. All too often, when users figure out what's wrong they disappear. Real world feedback for these odd issues is useful info for all.
Thanks.
Yeah true but i will post my conclusions if i get one. But it may take awhile. ![smile :)](https://forum.openmediavault.org/wsc/images/smilies/emojione/263a.png)
And if, from what I recall, you had installed a lot of stuff (removing/uninstalled afterwards), just start fresh with a blank SDcard and rebuild the server.
Although OMV5 is almost EOL, better to have it running with zero errors (on OMV5) than fighting with OMV6 with flaws.
Maybe in the meantime, RADXA will have an RaspiOS Bullseye arm64 update (make some support request on their forum, perhaps)
Yeah i am really considering to switch back to OMV5 . If i will get no conclusion out of my tests then i switch back.
On a sidenote, after some testing, I feel Pis don't do well with Jellyfin:
I tried to have it on my network, one Pi4 (4Gb) bullseye arm64 running docker jellyfin and serving several clients on the house.
It streammed OK "low bitrate" files but would struggle for Hi-quality MKVs.
And this was with only 1 client connected.
They are no powerhouse for sure. I managed to stream 2x 4k mkv one on my phone and one on my parents 4kTV without stuttering but with hardware accleration. Of course real server hardware is better
and i count the days until i can take the Pi to its retirement.