I've been running 5.0-beta12a without issue for a long time and I broke my #1 rule "Don't Upgrade Unless Absolutely Necessary". Well I "Upgraded" to  5.0.4 and it turned out to be a disaster.

I primarily use my server from OS 10.6.8 to record TV programs with EyeTV which we delete after watching. But I do use it without issue from OS 10.4.11 thru 10.8.x from PPC and Intel based Macs for back up using SuperDuper.

 

The first issue was when deleting a program after watching in EyeTV.  I got and error saying the "File Could Not Be Found". That happened every time I tried to delete a file within EyeTV.

Next problem was 8 hours of scheduling was ignored, probably because EyeTV could not find or recognize the scheduling files it places on the drive for each program. My wife didn't think that was fun.

So I took a look from a finder window to the TV Share and noticed that files that were many gigabytes in size were showing as zero but if I looked again s few minutes later the size would either show correctly or files that were previously correct would show up as zero.

One minute EyeTV would play a file that it listed and the next it could not find the file or it listed it as unplayable.

I did do a test record after updating and it seemed to work but then it went nuts (non tech term).

What is going on?

I reverted back to my previous 5.0-beta12a and all is well again.

What changed in 5.0.4 for afp to cause these issues?

Am I stuck at 5.0-beta12a?

The way SMB and AFP shares were advertised from unRaid changed in one of the releases (5.0.3 I think), it's in the release notes.

 

In earlier versions The AFP share was advertised as SERVERNAME and SMB as SERVERNAME-SMB. It is now the opposite. SMB is advertised as SERVERNAME and AFP is advertised as SERVERNAME-AFP.

 

You can either remap your shares, or change unRaid back to the earlier way of advertising share names.

 

http://lime-technology.com/forum/index.php?topic=30452.msg273750#msg273750

 

What changed? Two things immediately come to mind:

 

 

1. The change in security. 'Root' no longer can access user shares. Create a userid and password on unRAID and access all shares that way.  Reset your stored OS X passwords by Mac RESTART, then going to FINDER/GO/Connect to Server...etc.

2. SERVER NAMES changed. OS X Mavericks has AFP all but gone...only TM uses it. To prepare Mac users for the upcoming change, the Names of servers is changed (see notes for 5.0.3). What WAS TOWER on a Mac is not TOWER-AFP and what used to be TOWER-SMB is now just TOWER.

 

 

Try these two and report back.

I guess we know who can type faster.

I guess we know who can type faster.

 

On an iPad even! 

Fast Typing, It's not Me!

 

Anyway I'm not even accessing the TV share through "Tower" or "Tower-AFP" that shows on the left of the finder window. I'm connecting to the server through a script on startup just to that share so it shows up like and external drive on the desktop.

Would any of that account for erratic behavior in file size from minute to minute.

I can still access the file in the finder window for that share.

If I set up a new user for that can I go back if it I still can't get it to work?

 

Fast Typing, It's not Me!

 

Anyway I'm not even accessing the TV share through "Tower" or "Tower-AFP" that shows on the left of the finder window. I'm connecting to the server through a script on startup just to that share so it shows up like and external drive on the desktop.

Would any of that account for erratic behavior in file size from minute to minute.

I can still access the file in the finder window for that share.

If I set up a new user for that can I go back if it I still can't get it to work?

Check your script to be sure it has the new name, 'Tower-AFP', or 'Tower', as the case might be.

I don't use EyeTV...are there settings there which point to an IP address? Or does it use filepaths?

No setting in EyeTV for an address.

You just set a file path by navigating to the Volume just like you would for any Mac app when saving a file then save it in EyeTV Prefs.

The volume must be mounted first before EyeTV launches and since it shuts down at night the Volume must be mounted everyday. It will try to mount the volume however if the server is running.

I know I had a script in there but I can't seem to find it now. Maybe I removed for some reason, so it must be mounting the volume by the path.

If so this all creates a problem since there is no way to include a user and PW in that path that I know of.

If you're connecting through a script, that script must have a volume name.

That volume name now ends with -AFP, or doesn't end with -SMB.

 

 

If you can't find the script, follow the instructions to revert back to the old volume naming convention.

(I think this is long term bad idea, but it might get you running again and would identify the problem as being the change in names.)

(See dirtysanchez's earlier link to the Lime-Wire instructions on putting the names back.)

You may be mounting the drive as a login item. Go to your System Prefs, Users & Groups and click on "Login Items". If you see your drive there, that's when it's being mounted.

 

Select the drive, and click the minus sign to remove it, then browse to your server media share using finder. Once you open the media share under it's new name, you'll get the drive on the desktop, and you can just drag the drive icon to the login items list and it will automatically mount that drive on the desktop when you restart.

 

This is a sever name issue for sure... I had the same issue but it was a backup script that couldn't find the mounted the share.

You may be mounting the drive as a login item. Go to your System Prefs, Users & Groups and click on "Login Items". If you see your drive there, that's when it's being mounted.

 

Select the drive, and click the minus sign to remove it, then browse to your server media share using finder. Once you open the media share under it's new name, you'll get the drive on the desktop, and you can just drag the drive icon to the login items list and it will automatically mount that drive on the desktop when you restart.

 

This is a sever name issue for sure... I had the same issue but it was a backup script that couldn't find the mounted the share.

+1  I forgot about the login items...this is definitely the preferred fix.

I must have removed the script because it was causing problems.

There is no login item for it either.

I actually had the users set up but I guess I was using root to connect.

I wrote a new Applescript as a login item with the user and PW that mounts the share as a volume then runs EyeTV instead of EyeTV running as a login item first. The script does work with my current beta version but I can't change back to 5.0.4 to test it until Saturday when nothing is scheduled and my wife is not here to freak out .

You might also look in the OS X utility  "KEYCHAIN ACCESS"...it should be keeping track of your server connections, etc., but there might be some out of date settings still lurking in there.

Ok, I checked the keychain stuff and server list and deleted everthing.

I installed unRaid 5.0.4 again by replacing the BZIMAGE and BZROOT files and got everything working after repairing  permissions.

Did some test schedules and recordings and deleted them..everything worked. This was in the morning. Later in the evening we were watching a few shows then deleted after and I got the file not found error while deleting again on every show I deleted. The connection deteriorated to the point that I could not log in anymore, I got server not found even when trying to connect via "Connect To Server" So what happened in between, the drives  spun down, The computer running OS 10.6.8 is set not to sleep. I restored my beta version and all is well again. I was able to connect with another computer running OS 10.4.11 via "Connect To Server" to change the files on the flash back. BTW I am using an Intel NIC card.

One thing that I notice is that these files are not flat files, they are packages that contain other files like tiffs as well as the mpeg video file and even with prior versions of unRaid only the mpeg file would get deleted and leave behind the tiffs in the package. So every now and then I go in and delete the remnants of the deleted files by hand.

Also way back when there was no APF I did the hack to get it running and wonder if remnants of that are still in there somewhere and maybe I should do a clean install. I now have a second server, clean install of 5.0.4, so maybe I may try it on that first.

I only use AFP for Time Machine. Apple has depreciated AFP for file sharing. Make sure that you now access the server using SMB, i.e., smb://... If your not using Time Machine turn AFP off in the server, see Settings->AFP.

I only use AFP for Time Machine. Apple has depreciated AFP for file sharing. Make sure that you now access the server using SMB, i.e., smb://... If your not using Time Machine turn AFP off in the server, see Settings->AFP.

Many of the apps I use do not play well with SMB.. Superduper and EyeTV will only work with AFP... I tried EyeTV with SMB and it won't even recognize the share as valid path. I also e-mailed the developer of Superduper prior to this and they said it needs AFP.

This server is being used more like a NAS to record to and play from for the most part.

However I solved the problem. The script that I mentioned was still in my system library and would try to keep mounting the share. I don't know why I didn't see it when I looked the first time but I found it and it was actually 2 scripts in tow places in the system. I removed them and also changed the way the server name is displayed back to the previous way to "Tower" and "Tower-SMB". I also had to put a new Applescript in the login items to mount that share via password before running EyeTV otherwise EyeTV would just hang. So far it's been working all day and night.