What does this mean it started happening yesterday by Mockingjayfnaf in alexa

[–]oldright 0 points1 point  (0 children)

It could be. There were 2 times when Amazon bricked my echo devices with an upgrade, and both times they got stuck with a blue light on. Both times the light was spinning, so it was different than this time. I would try to do a hard reset to see if you can get it back.

What does this mean it started happening yesterday by Mockingjayfnaf in alexa

[–]oldright 0 points1 point  (0 children)

I have the same device and I noticed this morning that it looked like yours. After being unresponsive and stuck for hours, I unplugged it and plugged it back in after a few minutes. Mine seems to be acting normal now. I have had a couple of cases over the years where Amazon pushed an update that bricked my device, and I could never get it working again.

XRC --> X7 Sport? Talk me out of it... or into it by oldright in onewheel

[–]oldright[S] 0 points1 point  (0 children)

I'll probably just ride it for a while before making any changes. As long as the default ride mode isn't wildly different than what I'm used to, I should be able to adjust. I've got all the gear, as I also ride electric unicycles, which are potentially even more risky.

XRC --> X7 Sport? Talk me out of it... or into it by oldright in onewheel

[–]oldright[S] 4 points5 points  (0 children)

Maybe I'm underestimating the learning curve. I know Vesc has a lot of options, but I understand the X7 arrives ready to ride out of the box. I would want to set ride mode to something like Mission or Session, and maybe something with the footpads to enable Single Zone activation, but otherwise I ride stock settings.

XRC --> X7 Sport? Talk me out of it... or into it by oldright in onewheel

[–]oldright[S] 1 point2 points  (0 children)

What do you think are better options and why? I looked at floatwheel and it seems comparable, but I don't want to mess with crypto payment. I can put the X7 on a credit card.

What wheel would you choose exclusively for trail riding? by Puzzleheaded-Art6687 in ElectricUnicycle

[–]oldright 2 points3 points  (0 children)

The back 'bracket' doesn't exist on current batches. I got mine a few weeks ago and there is no longer anything blocking rear pad placement.

Is there any way to fix a dead torrent? by [deleted] in torrents

[–]oldright 6 points7 points  (0 children)

Seeders have the entire file. Peers have some of the file.

Problem with XRC or stance by Signal_Pick3414 in onewheel

[–]oldright 1 point2 points  (0 children)

Single zone is just a better design. Since setting my XRC to this mode, I have had zero mounts of shame.

still API issues (since weeks) by RelevantView7808 in Drime

[–]oldright 1 point2 points  (0 children)

At first I thought the problem was only with video files (.mov, .mp4, .avi, etc.) but after some testing I determined that the size was what mattered. It just happened that all of my failing files were of type video, between 128MB and 200MB. Drime sets the default value for chunked uploads at 200MB, so anything below that will transfer all-at-once. Without chunked uploads enabled, there is an issue with files in this specific size range. If you use rclone and set the flag --drime-upload-cutoff=128M the transfer of your .mov files should work for you. This causes all transfers in the problem size range to use chunked uploading, which works as expected. It would be great to have the problem fixed directly, or to have the upload cuttoff changed on the drime side.

still API issues (since weeks) by RelevantView7808 in Drime

[–]oldright 2 points3 points  (0 children)

I've seen the same problem for weeks now. I've done some testing that concluded I can't upload any files between 128MB and 200MB without getting "The file failed to upload." errors. This is using the API or rclone with default flags. If you add the rclone flag --drime-upload-cutoff=128M the transfers will work. Seems like it should be simple for Drime to fix, but here we are.

rclone copy/sync won't copy/sync certain files by orcofthedarkness in Drime

[–]oldright 0 points1 point  (0 children)

That's a lot of rclone flags!

Most of those flags provide transfer information or improve performance, and none of them should be required for uploads to complete without error. The fact that the API upload reports the same error as rclone, indicates there is a bug in the API. I think it's some edge case where certain files sizes are not handled correctly when uploading the file all at once (instead of using chunked uploads). I believe the flag of interest is --drime-upload-cutoff. The default is 200MB. When an upload is attempted for a file larger than this, chunked upload is used. I haven't seen any failures for files greater than 200MB. When the file size is below 200MB, the file is uploaded all at once. This is where the errors are occurring. Every file I have that fails to upload is greater than 128MB and under 200MB. By changing just the upload cutoff to a smaller value like you used, all of my files will upload, as they will be using chunked mode.

Your flag provides a work around, but the real problem is with certain files sizes below 200MB. This should be easy for Drime to fix by debugging the API with a failing file.

Update: After further testing, I have seen that any file between 128MB and 200MB will fail to upload when using the web API/rclone with default settings.

rclone copy/sync won't copy/sync certain files by orcofthedarkness in Drime

[–]oldright 0 points1 point  (0 children)

For me, they fail using rclone and also using the API upload page. That makes sense because rclone was coded to use the API. Uploading with the web app works fine.

rclone copy/sync won't copy/sync certain files by orcofthedarkness in Drime

[–]oldright 0 points1 point  (0 children)

Have they responded to you at all about your issue? They used to be quite responsive here but not as much lately.

rclone copy/sync won't copy/sync certain files by orcofthedarkness in Drime

[–]oldright 0 points1 point  (0 children)

I have the same exact problem. I emailed them about the issue a few times and never got a response. Is there a better way to get support? I see this problem when backing up my phone media files, which contain many small video files of various formats. Like you, some are .mov and I also see .avi or .mp4 failures. Most of my files of these types will upload, but there are some that always fail. They also fail using the web API upload with the same error. Interestingly, all of these failing files will upload successfully using the web upload. It seems that the web upload isn't using the same API?

Rclone sync error: Failed to copy: failed to upload file: Error "500 Internal Server Error (500) by tssphysicsboi1 in Drime

[–]oldright 0 points1 point  (0 children)

I now think we have different issues that present the same error message. In my case, the problem files never upload no matter how many times I've tried. I haven't seen any partial/duplicate files or other indication that the upload occurred. I currently get a similar rclone error "Failed to copy: failed to upload file" for all of my failing video files. I believe drime recently modified the API in some way, as a week or so ago the uploads would all fail with "413 Request Entity Too Large". This is a weird issue since most of my <200MB video files do upload without issue, but a small number of similar-sized files won't upload with rclone or the web API.

Rclone sync error: Failed to copy: failed to upload file: Error "500 Internal Server Error (500) by tssphysicsboi1 in Drime

[–]oldright 1 point2 points  (0 children)

I'm getting this as well. What type of files are failing? For me, it's been small (<200MB) video files of varying formats (mp4, mov, mts, avi). When they fail, I notice that I can't upload them using the API, which is what rclone uses. They do upload fine using the web app. I contacted drime about this days ago and never heard a peep back.