yea i tired that that's the weird part
I've only ever tried this once but have since moved to Emby as this has DLNA 'built in' as does Plex, I didn't find it intuitive
Posts by geaves
-
-
If memory serves me correctly this is not possible due to the restriction of the USB.
-
hardware transcoding through Intel QuickSync
Yes, from the docker hub page
-
Best guess naming convention, usual naming for TV is;
<Folder name of series>
<Season 1 folder>
Name of Series - S01E01 - Title of Episode 1
< Season 2 folder>
Name of Series -S02E01 - Title of Episode 1
-
install pi-hole on a separate Pi
That's how I have mine, complete with unbound
Look at the guide for Plex here however, you can bypass the first part and use stacks, create a stack called Plex, copy that compose file (the bit in code) and paste into the stack, then edit the settings for your use. The great thing about using a stack is that you can change settings if the container throws any errors by simply stopping the container and editing it's stack then deploy it again and the changes will be initiated
-
command: docker swarm init
That's the video by dbtech, did you reboot after running that command
-
Thanks for your help again! I have just finished the whole process.
Excellent,
-
I should mention that the PC I installed here for teleworking during COVID is actually connected via WiFi and that therefore my data rates are pretty low. That is why I won't go for the temporary transfers to my PC and back to the server
Yes, wifi will be the bottleneck, even if it's 5Ghz
But via SMB it is definitely not locally, is it
No, that's one of the reasons I never use that approach, the only other way I would do this is to use like CloudCMD in docker, that is quick copying from one drive to another, or from one folder to another.
-
Via WinSCP I am doing the copying only locally on the server which should be a lot faster, shouldn't it
No it will be slower, as you are using sftp, I only ever use that way of copying if I am moving files 'outside' the share i.e. to a totally spurious directory.
-
Another question: I am atm copying all the files via SCP as I only want to duplicate them locally.
Personally I would have created one share added that to SMB, then under that share from windows create the folder structure as on your Raid 1, then copy files, this is much quicker than using WinSCP. Once you know you're OK before creating the second array, delete the SMB share then delete the shared folder, this is how I would approach it.
-
Might there be the option to just create an array out of the already existing data on sdd by adding the sdc drive
No, the drives need to be clean to create the second array, your points 1-5 look OK, this seems 'around the houses' but it's the only way I can suggest to ensure you don't lose any existing data.
But it will keep you busy
good luck -
Should I - once finished - go ahead with the above written, i.e. deleting the sdc from the array, wiping it as well and creating a new RAID 1 out of sdc and sdd
Only if the existing Raid 1 is intact, the idea of getting the data onto one of those drive was to ensure you had a backup, if removing the second 4TB the existing Raid 1 stays up, then create the second, but that means wiping both those drives again.
If this was me I would then copy the data from the existing array to the new 4TB array before rebooting
-
I was going to answer your first post but the above is odd behaviour, when you removed it, did you wipe and format it, Removing it from the array and wiping it should remove the signatures and not in essence add it back automatically.
But yes remove it again, wipe it, create a file system, then reboot see what it throws.
-
Containers have the "Restart Policy" set as "Unless Stopped".
You could try changing that to always
-
Should this happen?
Yes and no, what I was expecting was not that, what I'm guessing has happened OMV/mdadm has added those drives as spares, rather than actually add them to physically use them
If you look at your image the raid is in a clean state after removing that drive, but when I did this on my VM and removed a drive the raid was clean/degraded and I couldn't remove another.
I could suggest that you remove the 4TB but I have no idea now how this will behave. Looking at this output
md0 : active raid1 sdb[0] sdc[2](S) sda[1] the red would suggest that sdc is the second 4TB and it's a spare i.e. not physically active in the array.
The last thing I would want to happen is this to blow away your data, so I would go with what I was assuming to be the best option that way you know you can get the data off, then remove that second 4TB. If the raid stays as clean and the data is still accessible you can start start by wiping the two 4TB and creating a second raid. If the blows up it doesn't matter as you've got the data on that 4TB.
Sounds confusing, it does to me as I wasn't expecting that outcome.
-
Installed on a raspberry pi model 3B+
That's why, cloundcmd is for amd64 there is no image for arm based boards
-
Really?! Well .... AHHH that explains it.
There is a way around it, someone posted a solution on here but I can never find it
they changed one of the options, you might find some info here -
I see. I accomplished that by setting up shared folders from the merge. The only problem was I couldn't use /sharedfolder/ for docker mount points; i had to point to /srv/[fuse id]/[media folder], but for some reason i couldn't get permissions correct and the containers, even though running with PGID/PUID of a group/user with full rwe access, couldn't create folders... That's part of why I was trying to use that x-systemd.requires=
You can't use the fuse/mergerfs mount point for docker containers particularly the /configs, easiest way around it is to a share on single drive within the mount, unless you have a spare drive which is what I am using
-
I followed Techno dad life's tutorial:
What hardware are you installing this on
-
connected to the router using Cat5e cable - Gigabit<->Gigabit
What it says on the tin doesn't mean that's what you get, I never, ever connect hardware to a router I always use a switch.
which holds 2x4TB WD Red drives NTFS formatted so they can be shared using Samba
Not necessary, if fact a number of threads on here and Pi forums suggest using ext4 due to transfer speed degradation, for sharing the file system makes no difference.
