Author
Topic: New Media Navigation Facility (Read 7990 times)

There was a bug in 0710 beta 3 where update media was not happening on remote shares. Sorry, I haven't fully tested this yet on beta 4 or RC1. On beta 4, update media did add all my previous videos with meta-data from the remote share. On beta 4, update media has not added any meta data to the few videos without pre-existing meta-data. New videos ripped with beta 4 have .id3 files on NFS shares.

On the log messages, I'm seeing the same type of log messages on my NFS server. One message thread I found on google suggested increasing the mount's timeout value to something like 10 minutes from a default of 60 seconds. Currently it looks like /etc/auto.PlutoStorageDevices sets the timeout to 7 seconds. I haven't tried changing the timeout and don't know what the ramifications would be under LMCE.

on the messages, I'm assuming this is just automounting - LMCE mounts shares and unmounts them as it needs them rather than leaving them mounted all the time, using autofs (I think). Its completely transparent to the user - unless you are sitting there reading the messages log!

As for id3 files - as I said in my previous post, if you haven't added any metadata to your video files manually, then it won't create an id3 file for it - that is how it is supposed to work. No metadata, no need for an id3 file. It sounds like your video files are downloaded torrents, so they won't have any metadata to begin with. Sounds like Roy is talking about ripped DVDs (he actually says "rip") - when LMCE does the rip, it also tries to find some metadata online from Amazon for your DVD. If it finds this, it writes the metadata into the database, and thus UpdateMedia creates an id3 file on the share to contain that metadata as well (ie the metadata is stored in 2 locations).

So he will see id3 files, but you will not. Try my suggestion above - login to the admin site, find one of your video files, add a few attributes to it, hit the sync button, then check your share and you will find an id3 file.

Have you selected Filename in the Sort menu for video media browser? Do you see your folder structure and files in there? If yes, then everything is working. "Sort"ing by other attributes isn't going to work very well if you haven't got any attributes in the database! If all you have are downloaded torrents, then you won't have any attributes for it to sort by - it can't just magically know things like "performer" et al, they aren't included in the torrent so you have to enter those manually. Try ripping some common DVDs and you will see that they have attributes (from Amazon) and will display in the other "Sort"s. Or rip some CDs as their attributes are downloaded from the Internet as well. MANY mp3s you download as torrents DO have attributes already embedded (in fact I would say most), so that is a good test as well.

Yes I have selected Filename in the SORT menu, but it goes from showing me all my files to just showing tv_shows_1. Nothing else. And I'm not going to put metadata on 1100+ videos.

Going back to my first topic on this email. A better media browsing facility is necessary. That is the main reason so many people bought a mac mini to use as a media player, because its damn easy to browse your media and play. You dont need any metadata. You dont need a complicated share structure. You just mount the share on the mac and navigate through the tree with FrontRow and a 6 button remote. Of course it required installing non-Apple codecs to play DivX files and this makes it crash some times. Not to mention that the SMB and NFS client libraries provided with MAC/OS sux big time, but that's another story

I have watched other threads on this forum and there is people asking for this. I think you should consider it. This is the most important feature LMCE is lacking so far.

I'm not going to argue, I have tried to help and you haven't listened on several occasions.

- I never said you had to apply attributes to 1100+ videos, I just suggested one video so that you can see how it works.

- I never said that you had to apply ANY attributes to get the folder/file navigation working, you don't, it does it automatically

- that you have tv_shows and no folders means you have a problem in your system somewhere

- to state it one final time... browsing by folders and files is there already, out of the box, no further configuration or metadata required. It is extremely easy to use, and I can navigate around many thousands of video/audio files in seconds. It is completely intuitive to use as it is exactly what you will be used to in other systems, ie a simple heirarchy of files and folders reflecting what you have on your media share.

Using the metadata sorts is much more sophisticated and intelligent, but to be perfectly honest, I almost always use the file/folder heirarchy sort - always for video. Although I sometimes use metadata for music when I want to pick all from a particular genre and play them. So I'm sorry, you are wrong it isn't a feature that LMCE is missing, it has always been there, it just isn't working on your system for some reason.

Its been so long since I had the same problem (tv_shows_0 and 1) that I can't remember what causes it. Will leave that for someone else to suggest solutions as I have typed enough already! But rest assured a working system has this, and I imagine that most LMCE users use it all the time like I do.

If you are pre-0710 beta 4, then upgrade to RC1. Beta 4 introduced some NFS automount fixes. BTW, I just did a new install of RC1, added my two file servers each with an NFS partition, rebooted, then ripped one movie to an NFS share, then watched it. RC1 is so far working nicely.

As stated earlier in the thread, make sure PK_Users is "Pluto's structure". If you change this, then reboot your core/hybrid.

In the above example, I have two NFS shares, devices 39 and 41, using Pluto's structure. If your NFS share's PK_Users is set to "Public", then you would see the share under /home/public/data/other/NFS Share [XX].

The "NFS Share [XX]" directories are just links to the automount device as you can see by using ls -l

I have reinstalled RC1 at least 4 times since thursday. I've been forced to delete a share and re add it (all manually) after a simple reboot. I'm sure this is not normal. I'm at a complete loss. I appreciate any ideas. I still cannot see my videos when I sort on Filename.

One more thing. The server that has the NFS share, is also the gateway (192.168.1.3) of my network. My LinuxMCE box has 2 cards. One gets an IP Address using DHCP. The other is set by the installer to 192.168.80.1 and it runs DHCP on that interface: http://download.erasmix.net/linuxmce/Screenshot-3.png Could this be the root cause of the problem I'm experiencing?

One more thing. The server that has the NFS share, is also the gateway (192.168.1.3) of my network. My LinuxMCE box has 2 cards. One gets an IP Address using DHCP. The other is set by the installer to 192.168.80.1 and it runs DHCP on that interface: http://download.erasmix.net/linuxmce/Screenshot-3.png Could this be the root cause of the problem I'm experiencing?

Roy, I already disable my firewall on the dcerouter, because I use the web admin from a different box. The gateway server (192.168.1.3) also has two network cards and the firewall filters the external network only, so I have no need to firewall the nfs ports.

I'm also aware that, because the file server is on a different network than the dcerouter, it wont be discovered until I added manually thru the web admin interface.

Do I still need to limit the NFS ports on the server and enable pass thru if nothing in the internal network is being filtered by a firewall?

I know this is not an easy challenge, so I sincerely appreciate you guys helping. I'm willing to try everything.

First, exporting root on an nfs is pretty dangerous, so please eliminate it unless you really need it. shudder

Second, let's only allow internal IP's to connect with 192.168.0.0/16. That should allow the external interface on the dcerouter and any future MDs on the internal interface to connect.

Third, the permissions really need to be what I've specified (they took a couple of days to figure out). You probably could substitute sync for async as it is just a performance option. The no_root_squash is critical. Basically the dcerouter needs any share to look exactly like it is an internal disk with regards to ownership/permissions. Further the dcerouter requires the ownership be root:public as viewed from the dcerouter. What this means is the ownership on the files in the share must numerically match the dcerouter's ownership. Currently root:public is 0:1002 on the dcerouter. root squashing changes root (0) to nobody (65534). I really hate this as it is a major security hole, but this is the only way I could figure to get it to work.

Dont worry about the / share. Its just me on my network at home. I'll remove since I no longer need it.

I saw the (async,no_subtree_check,rw,no_root_squash) in the article I used to setup my network share, but I thought that (rw,insecure) would be a superset. Anyways I just changed to /usr/fatboy/CleanTorrents 192.168.0.0/16(async,no_subtree_check,rw,no_root_squash), I dropped the share, recreated it, and quick reloaded the router.

Sorry, it made no difference. Sorting by Filename only shows tv_shows_1

would it be possible to setup a reproduction? Is there a way for me to collect diagnose information?

I noticed that, some times, after rebooting, my NFS share just doesn't show any files at all. It takes about 2-3 OS reboots for this to happens. I also noticed that, when this happens, I can't see any files, but when I sort on Filename, I see the name of the share below tv_shows_1, but when I select it, its empty. At this point I'm forced to delete the share and re add it again. It just happened again when I turned on th machine to collect the info you asked for. Therefore I decided to collect two sets of data, one with the shared gone bad, and with the new share showing files in it.

Now on to the flakiness. I had a similar problem when I was first getting NFS going. It turned out to be a bad ethernet switch between my NFS server and my dcerouter. If you can, try eliminating any hardware between neo and the dcerouter.FYI, I'm using D-Link's DGS-2208 gigabit switches now a days.

I did yet another fresh install (no keeping settings at all). I added the file server as you said below, but that was the original way I set it up. On the share, I notice you didn't ask me to specify NFS on "Filesystem", so I didn't. I got exactly the same result. On the NFS "flakiness", after I rebooted my system (with the remote, thru the advanced menu), it happened again! I be willing to connect the server to the dcerouter directly if I wasn't sure I don't have a network router problem. By the way, I can see the device mounted:

Besides this didn't happened with Beta4. I'm actually tempted to go back to B4 and give it a try.

Finally I wanted to ask you. On a previous post you asked me to find /home/public/data -name "NFS*" -print. Well that didn't return anything (see my previous posting). I just ls -l /home/public/data and this is what I got:

I was wanting to see the links to the share under /home/public/data. I didn't realize that you had changed the description from the default of "NFS Share" to "CleanTorrents".

For example, if the NFS share's description is the default of "NFS Share", then the links would be "NFS Share [XX]" so I just picked a wild card match of "NFS*". In your case, if your NFS share's description is "CleanTorrents", you could specify the name match pattern of "CleanTorrents*".

Basically what I was wanting to confirm was the mapping of the links using pluto's structure. Here's what I was hoping to see something like:

If there are no found links, then I'd recommend rebooting the dcerouter and trying again. If still none, then we are seeing a problem.

If the link found was something like /home/public/data/other/NFS Share [39], then we would have a config problem as it is using "Public" instead of "Pluto's structure" for the nfs share's PK_Users field.

If the links are as expected, then we first confirm that we can see the nfs share via the link using something like: