MiniDLNA PBI Not Working (in VM)

[joeschmuck]

Just loaded 9.1.1 Beta 5 as a clean install on a VM. Loaded fine. Attempting to install MiniDLNA PBI from the Plugins Screen. The plugin was installed and I configured the storage directories.

The problem, when trying to start the plugin I get the following error message below (I included a bit extra to show the installation messages). Not sure what the problem is as I didn't have this problem when testing 9.1.0RC2.

Code:

Aug 17 18:47:51 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/sbin/pbi_add  -i /var/tmp/firmware/pbifile.pbi
Aug 17 18:47:51 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec 2 /usr/local/sbin/pbi_info  -v
Aug 17 18:47:51 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec 2 /usr/local/sbin/pbi_add  -f --no-checksig /.plugins/minidlna-1.0.25_1-amd64.pbi
Aug 17 18:48:09 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec  2 cat /usr/pbi/minidlna-amd64/freenas
Aug 17 18:48:10 freenas notifier: Performing sanity check on nginx configuration:
Aug 17 18:48:10 freenas notifier: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
Aug 17 18:48:10 freenas notifier: nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Aug 17 18:48:11 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:48:11 freenas kernel: arp: 192.168.1.30 moved from 02:e8:a8:00:08:0b to 90:a4:de:99:db:de on em0
Aug 17 18:48:13 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:48:13 freenas last message repeated 2 times
Aug 17 18:48:16 freenas manage.py: [plugins.utils:80] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/status: timed out
Aug 17 18:48:18 freenas manage.py: [freeadmin.navtree:473] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/treemenu: timed out
Aug 17 18:49:27 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:49:52 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:49:52 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden set defaultrouter-ipv4 dlna_1 192.168.1.1
Aug 17 18:49:53 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:49:53 freenas last message repeated 3 times
Aug 17 18:49:58 freenas manage.py: [freeadmin.navtree:473] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/treemenu: timed out
Aug 17 18:50:09 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:50:14 freenas manage.py: [plugins.utils:80] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/status: timed out
Aug 17 18:50:20 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:50:25 freenas manage.py: [plugins.utils:80] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/status: timed out
Aug 17 18:50:25 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list  -v
Aug 17 18:50:42 freenas last message repeated 6 times
Aug 17 18:50:47 freenas manage.py: [freeadmin.navtree:473] Couldn't retrieve http://192.168.1.23/plugins/minidlna/1/_s/treemenu: timed out

 

[joeschmuck]

I don't know what I did but I deleted the PBI and reinstalled it, now it's working. In the middle I did try to install the PBI manually and it failed. Very odd. I'd be curious if others have problems like this. I'm starting to think that the PBI wasn't fully installed.

 

[paleoN]

I'd be curious if others have problems like this. I'm starting to think that the PBI wasn't fully installed.

This was possibly a timing issue/race. AFAIK, the timeout for plugins is now generated based on the number of total plugins installed. This may have decreased the timeout for a single plugin, but I would need to check the code. The VM was probably just "slow" for whatever reason the first time around.

 

[joeschmuck]

I thought it worth mentioning. I'm using VMware 8, same setup I always use for testing. Could have been a slow network issue, maybe there were too many people trying to d/l plugins at the same time? Who knows. It's working now. I'll probably try it all over again and revert to my snapshot before loading the OS. I have a basic set of 4 VM Drives as a RAIDZ1 with some data on it. It automounts without failure. Saves a lot of time! Then it's just a few simple configuration changes and I can start to play with it.

Right now I'm playing with libinotify to see if I can get that working. So far I haven't.

 

[paleoN]

I thought it worth mentioning. I'm using VMware 8, same setup I always use for testing. Could have been a slow network issue, maybe there were too many people trying to d/l plugins at the same time?

It's not with downloading the plugin. That timeout is when it's enumerating/attaching plugins to the tree menu.

Right now I'm playing with libinotify to see if I can get that working. So far I haven't.

I hadn't seen that before. Not sure how functional it is:

The IN_OPEN, IN_CLOSE_WRITE and IN_CLOSE_NOWRITE events are not yet implemented, so the relevant tests are known to fail.

The ports also been abandoned since 24 Oct 2011. :( This would be really nice to have.

 

[joeschmuck]

With respect to libinotify I received this message from the the person who wrote the code.

Hi Joe,

It works and mostly covers the usual use cases. It just does not support some kinds of events, but the key events work well. There were some success cases on NetBSD and FreeBSD. And it is already included into FreeBSD ports, AFAIK.

Thank you for your interest,
Dmitry

I'm about to go on vacation so I don't have the time to do anything with it for now, maybe in a few weeks after I return. I did use pkg_add -r libinotify in the dlna jail but that didn't show that it worked. I am unaware of any special setup to make libinotify work and monitor specific locations. There was a comment about making a change to a boot parameter to increase the max files. If you do a web search on libinotify it will come up.

EDIT: I located the other bits of info I mentioned above:

For a typical desktop, add the following line to /boot/loader.conf, then
reboot the system:

kern.maxfiles="25000"

 

[paleoN]

With respect to libinotify I received this message from the the person who wrote the code.

That does look promising.

I did use pkg_add -r libinotify in the dlna jail but that didn't show that it worked. I am unaware of any special setup to make libinotify work and monitor specific locations.

Well it wouldn't. The major commits to make minidlna cross-platform was to throw #ifdef's around the inotify bits of the code. OK, that & some code refactoring.

EDIT: I located the other bits of info I mentioned above:

AFAIK, that's for UFS only.

 

[Tomec]

Hi everybody,
I got a similar problem with the plex media server and I am not lucky to solve it by reinstallation... I set up the volume, the dataset, the share, the jails etc. as described in the tutorial. But when I try to start the plugin service the message "some error occurred" is shown and nothing happens.

Does anybody has an idea what the reason for this problem is and how to solve it?
Thx for your support.

P.S.: I am using FreeNAS-9.1.1-RELEASE-x64 (a752d35) with VMWare Fusion on a MacBook Pro. The virtual volume (for test reasons only one) has a size of 8GB.


Oct 23 14:14:46 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jls

Oct 23 14:14:46 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/sbin/pbi_add -i /var/tmp/firmware/pbifile.pbi
Oct 23 14:14:46 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec 2 /usr/local/sbin/pbi_info -v
Oct 23 14:14:47 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec 2 /usr/local/sbin/pbi_add -f --no-checksig /.plugins/plexmediaserver-0.9.8.6.175-amd64.pbi
Oct 23 14:15:05 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/sbin/jexec 2 cat /usr/pbi/plexmediaserver-amd64/freenas
Oct 23 14:15:08 freenas notifier: Performing sanity check on nginx configuration:
Oct 23 14:15:08 freenas notifier: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
Oct 23 14:15:08 freenas notifier: nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Oct 23 14:15:10 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list -v
Oct 23 14:15:11 freenas last message repeated 3 times
Oct 23 14:15:15 freenas manage.py: [plugins.utils:87] Couldn't retrieve http://192.168.178.27/plugins/plexmediaserver/1/_s/status: timed out
Oct 23 14:15:16 freenas manage.py: [freeadmin.navtree:473] Couldn't retrieve http://192.168.178.27/plugins/plexmediaserver/1/_s/treemenu: timed out
Oct 23 14:16:55 freenas manage.py: [common.pipesubr:57] Popen()ing: /usr/local/bin/warden list -v
Oct 23 14:17:00 freenas manage.py: [plugins.utils:87] Couldn't retrieve http://192.168.178.27/plugins/plexmediaserver/1/_s/status: timed out

Edit: (Cyberjock)- changed color of font from bright green to black.

 

[joeschmuck]

Did you reboot the FreeNAS VM? here is a Plex thread that deals with this problem, you should go look for it. Also please do not post that nasty green color in the future, change the color to all black or something that contrasts the white background.

 

[Tomec]

Thx for your respond and sorry for the color, next time I will change it.
I rebooted it several times. Without success... I checked the other posts, but I couldn't find one that is dealing with a similar problem (except of this one here ;)

I just noticed that there is no entry of plex media server in the tree menu although I installed it.

 

[Sergiu Voicu]

Hi guys,

I ran into the same problem (both for MiniDLNA and PlexServer) and I managed to find the root cause and I've thought to share it with you.

So, the reason was that I have changed my home router and the new one was assigning a different subnet of IPs: the old one was assigning 192.168.123.0/24 while the new one was using 192.168.178.0/24.

And since when I have installed the FreeNAS the old router was in place, the jails configuration was set using this initial subnet (192.168.123.0/24). After I have replaced the home router, it started assigning IPs from the new subnet (192.168.178.0/24) and of course the jails configuration didn't adapted and it was still using the old IP addresses.This lead to the problem that the service was running, but it was bound to an IP which was unreachable. So the solution was either to change the IP subnet which is being assigned by the home router to match the initial settings (from 192.168.178.0/24 back to 192.168.123.0/24), or the other way around: to update the jails configuration to match the new IP subnet.

Hope someone will find this useful :)

 

[joeschmuck]

My situation was not an IP address issue. Can't speak for others.