Amahi Forums

I recently began an effort to bring order to the chaos that is my media collection. This has resulted in a good deal of renaming and deleting (similar) files, but not actually much new information. I know that changing lot of files is not greyhole's strong suit, but I'm beginning to wonder if I need to start over from scratch.

The greyhole queue keeps getting stuck in endless loops where it repeats the same small set of commands over and over. Viewed in real time using the TAIL command, I can often see a pattern emerge visually, based on the different line lengths because it is moving so fast. Using the GH Logmon app, I can view a snapshot of the queue. I'll search for unique piece of text from the queue using the browser's find command, and see that text repeated over and over dozens of times.

I am able to stop the queue to from looping using the procedure on the greyhole troubleshooting page (https://wiki.amahi.org/index.php/Greyho ... Work Queue), but eventually the loop starts again during the subsequent fsck. At this point I'm not certain it will ever complete an fsck.

I had this happen infrequently with amahi 9, but it's become more common for me since upgrading to amahi 10. Of course, this could just be a coincidence since I've done similar large scale adds/moves/deletes before without this happening. I'm wondering if anyone else has seen an increase in greyhole problems since amahi 10?

If this continues I'm not really sure of my next step. I prefer to not rebuild my landing zone unless absolutely necessary because of the possibility this error could continue to occur. If it does and I've deleted my landing zone shares, then I'm even worse off. At least for now most of my files are readily accessible.

I'd appreciate some help determining the cause, and the best next step. I've included some troubleshooting info below. This represents items 1 & 2 at the top of the troubleshooting page. I haven't included #3 because I don't know how to capture the results to a text file, and the raw results are rather lengthy. #4 isn't included because when I executed the command it asked for a password. I entered my password, the only one I know to be associated with my hda, and it was rejected with an error (see below). I'm not sure what the error means.

#1
4.11.9-200.fc25.x86_64
samba-4.5.11-0.fc25.x86_64
amahi-greyhole-0.10.10-1.x86_64

#2
smb.conf https://da.gd/E5WD
greyhole.conf https://da.gd/knoR

#4
[root@hda ~]# mysql -u root -p -e "select * from disk_pool_partitions" hda_production
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Thanks in advance.

This has resulted in a good deal of renaming and deleting (similar) files, but not actually much new information.

Did you do this through Samba or via command line?

I had this happen infrequently with amahi 9, but it's become more common for me since upgrading to amahi 10.

I don't believe it's related to #Amahi. This release will likely correct your issue.

We have not updated #Amahi yet, but expect to soon.

The changes were made from a windows PC over the network, so samba I guess.

Hopefully the GH update will help.

The good news is that it appears to have completed an FSCK today without getting stuck in a loop. The landing zone is empty of files so I'm less concerned about data loss if I need to do something else. I performed a second FSCK just to be sure, and it completed as well, but I noticed something odd. The last few tasks on the second FSCK were exactly the same as the prior one. I scrolled up and saw that the sequence (below) of "Now working on task..." followed by "WARNING! No copies of the file are available..." was repeated hundreds, possibly thousands of times. After the warning there is never a resolution or action. This explains why they are showing up in multiple FSCK.

Jul 31 19:16:05 INFO fsck_file: Now working on task ID 75210: fsck_file Videos/insert filename
Jul 31 19:16:05 WARN fsck_file: WARNING! No copies of this file are available in the Greyhole storage pool: "Videos/insert filename

I couldn't possibly recognize every file, but it just so happens that I did the last one. It is a file that was sorted and moved to a sub-directory some time ago. It wasn't sorted recently while I was experiencing the loop problem. The path in the FSCK results is the original unsorted path. I checked and the file exists in the sorted directory as it should. It appears the FSCK is generating tasks based on old information. Is there a painless way to clean up this old info?

Is there a painless way to clean up this old info?

Yes do the following for syntax: There are options that will delete metadata with no file copies and orphaned files.

This is a followup to the previous discussion.

I was able to use the greyhole option to remove orphaned metadata so I no longer see references to long deleted files. Unfortunately I am still seeing the problem where greyhole gets stuck in endless loops; repeatedly performing the same small group of tasks. I can stop the stuck queue, but I do lose any unprocessed changes.

A greyhole update was previously mentioned. It appears my greyhole app is based on version 0.10.2. Has the latest greyhole update been released?

In addition to my GH queue getting stuck, I recently had a bunch of new empty folders with gibberish names appear in some shares. It seems to have only happened once, but it left behind dozens of such folders. The affected shares are also my most active, which makes me wonder if these folders are something temporary that wasn't cleaned up when my queue went bonkers. I've been able to delete most of the folders, but a few of them in each share simply will not go away. When I try to delete them windows doesn't really give me an error, they just don't delete.

I also noticed another, possibly related, thing. I thought I might try deleting the folders using the extplorer app. When I go to those shares on the landing zone disk, I see many more folders than windows shows, and most of the folder names are simply "false". For example, in my TV share, windows shows 268 folders, extplorer shows 988.

Are my shares completely screwed up? Would I be better blowing them away and starting from scratch?

Check your Greyhole version via command line: Should be 0.10.10 for Fedora 25.

If you don't have the latest, do the following:

Turns out I did have version 10.10. I mistakenly thought the version matched the one displayed in apps for the greyhole UI app.

We have a new version of Greyhole in testing.

Expect release first thing next week if all goes well.

You are welcome to help test. See bug 2275.

Please understand this is in testing so if anything goes wrong, you will have to sort it out. Don't expect any issues but wanted you to be aware.

I'll try anything at this point. I see the rpm path, but I don't know how to install the update. Can you give me the complete command line sequence?

I cleaned out my TV share and rebuilt it from scratch. This got rid of the empty gibberish folders, but the queue is still getting stuck when I rename/move multiple files at once.

I am trying to use the Sonarr app to organize my media collection. Sonarr scans a television series folder, selects the best version of each episode, then renames and moves them into new folders. Depending on the show, this rename and move operation might involve a couple hundred files renamed in quick succession. Immediately after such an operation, windows explorer will reflect the changes, and greyhole starts working in the background to process the changes. This is where things go wrong.

As I said above, more often than not, shortly after greyhole starts to process the files it gets stuck in an endless loop. The bug report mentions an endless loop while making copies. These files don't have copies, but it still could be related.

Every time I have to stop greyhole and purge the queue, I lose the unprocessed changes. The previous file structure is still intact so I don't lose anything, but I'm not making headway with my file organization efforts.

Do the following: