Thanks Squid, works fine now.

18 minutes ago, Squid said:

What's on line 1846. And some before and after

Sent from my LG-D852 using Tapatalk
 

switch (category) {
	case 'network:':
	$("#MainCategory").hide();
	$("#NetworkCategory,#NONE").show();
	$("#network").prop("disabled",true);
	break;
	case 'MediaApp:':
	$("#MainCategory").hide();
	$("#MediaAppCategory,#NONE").show();
	$("#MediaApp").prop("disabled",true);
	break;
	case 'MediaServer:':
	$("#MainCategory").hide();
	$("#MediaServerCategory,#NONE").show();
	$("#MediaServer").prop("disabled",true);
	break;
	case 'tools:':
	$("#MainCategory").hide();
	$("#ToolsCategory,#NONE").show();
	$("#tools").prop("disabled",true);
	break;
	case '':
	$("#All").prop("disabled",true);
	$("#NetworkCategory,#MediaServerCategory,#MediaAppCategory,#NONE,#ToolsCategory").hide();
	$("#MainCategory,#New").show();
	break;
	case 'NONE':
	$("#NetworkCategory,#MediaServerCategory,#MediaAppCategory,#NONE,#ToolsCategory").hide();
	$("#MainCategory").show();
	break;
	}
	$('#BackToTop').hide();
	if ( category != "NONE" ) {
	if ( category == "INITIALIZE" ) {
	category = "NONE";
	var initialize = true;
	enableButtons();
	$("#All").prop("disabled",true);
	$("#NetworkCategory,#MediaServerCategory,#MediaAppCategory,#NONE,#ToolsCategory,#Total1").hide();
	$("#MainCategory,#New").show();
	$(".allButtons").prop("disabled",false);
	}
	$("#Total").html("Searching... <img src='/plugins/community.applications/images/spinner2.gif' style='height:30px;width:30px'>");
	if ( (category == "New") || (category == "All") ) { category = ""; }
	var sortOrder = getSortOrder();
	var maxPerPage = getPerPage();
	$.post(URL,{action:'get_content',category:category,newApp:newApp,sortOrder:sortOrder,windowWidth:windowWidth,maxPerPage:maxPerPage},function(data) {
	if (data) {
	$('#templates_content').html(data);
	readMore();
	myCloseAlert();
	setToolTip();
	}
	description = "Recommended Applications: <font color='red'>"+description+"</font>";
	$("#Category").html(description);
	$("#updateButton").prop("disabled",false);
	});
	}
	$('#BackToTop').show();
	$('.dockerSearch').hide();
	setSortOrder();
	}
	function mySearch(filter) {
	<!-- remove any html tags from the filter -->
	filter = filter.replace(/<(?:.|\n)*?>/gm, '');
	$('#searchBox').val(filter);
	if ( $("#searchButton").hasClass('fa-search') ) {
	$('#searchButton').toggleClass('fa-search fa-remove');
	}
	initDockerSearch(1);
	}
	function initDockerSearch() {
	$("#maxPerPage").prop("disabled",true);
	dockerSearch(1);
	$("#sortorder").attr("data-docker","searching docker");
	$("#sortorder").attr("data-section","");
	$("#sortorder").attr("data-selected_category","");
	enableIcon("#categoryIcon,#subcategoryIcon",false);
	}
	function dockerSearch(pageNumber) {
	var filter = $('#searchBox').val();
	var dockerURL = "https://registry.hub.docker.com/search?q=" + filter;
	$("#sortorder").attr("data-docker","searching docker");
	$(".appButtons").prop("disabled",false);
	$("#AppStore").prop("disabled",true);
	$("#AppsOnly,#New,#UNCATEGORIZED,#All,#sortButtons").show();
	enableIcon("#sortIcon",true);
	$(".dockerSearch,#templateSortButtons").hide();
	$("#Total").html("Searching... <img src='/plugins/community.applications/images/spinner2.gif' style='height:30px;width:30px'>");
	$("#Category").html("DockerHub Search Results For <font color='red'>"+filter+"</font> <span id='pageNumber'></span>");
	var sortOrder = getSortOrder();
	myAlert("Searching dockerHub", "Retrieving <strong><font color=red>"+filter+"</font></strong> page <strong><font color=red>"+pageNumber+"</font></strong>","/plugins/community.applications/images/spinner2.gif","40x40");
	$.post(URL,{action:'search_dockerhub',filter:filter,page:pageNumber,sortOrder:sortOrder},function(data) {
	if (data) {
	$('#templates_content').html(data);
	readMore();
	myCloseAlert();
	setToolTip();
	}
	});
	}

CA.html

2 hours ago, Squid said:

the pop up never closed for some reason.

Adblocker? I know I had some popups not working correctly after I switched adblockers and forgot to whitelist my server.

On 6/11/2017 at 0:41 PM, trurl said:

Adblocker? I know I had some popups not working correctly after I switched adblockers and forgot to whitelist my server.

Doubt it, but doesn't hurt to try.

 

@DZMM  Completely at a loss.  The error of

Uncaught TypeError: Cannot read property 'childNodes' of null    at ca (dynamix.js:5)    at ua (dynamix.js:5)    at n.fn.init.append (dynamix.js:5)    at n.fn.init.<anonymous> (dynamix.js:5)    at K (dynamix.js:4)    at n.fn.init.html (dynamix.js:5)    at Object.success (Apps:1846)    at i (dynamix.js:4)    at Object.fireWith [as resolveWith] (dynamix.js:4)    at z (dynamix.js:6)

doesn't jive with the line triggering it of

				$('#templates_content').html(data);									
				

Edited June 12, 20179 yr by Squid

I think CA is coming up with the wrong template for my ownCloud docker.  The default Appdata Config in the CA template is '/appdata/cache/ownCloud'.  This was in a template I updated weeks ago.  In the template on my repository it is '/appdata/cache/owncloud/config'.  What is causing CA to get the wrong template?  Or is it an error in my template?

1 hour ago, dlandon said:

I think CA is coming up with the wrong template for my ownCloud docker.  The default Appdata Config in the CA template is '/appdata/cache/ownCloud'.  This was in a template I updated weeks ago.  In the template on my repository it is '/appdata/cache/owncloud/config'.  What is causing CA to get the wrong template?  Or is it an error in my template?

Not seeing that.  I did an install, changed it to /appdata/cache/ownCloud/blah, then did a reinstall using default values and it came up with /appdata/cache/ownCloud.  Are you sure you didn't hit Edit (the gears)?

25 minutes ago, Squid said:

Not seeing that.  I did an install, changed it to /appdata/cache/ownCloud/blah, then did a reinstall using default values and it came up with /appdata/cache/ownCloud.  Are you sure you didn't hit Edit (the gears)?

So it defaulted to the '/appdata/cache/owncloud/config' when you did the default from CA?  I didn't edit it.  In fact 'My-ownCloud' doesn't have that mapping so I couldn't edit it.

I do not have the same path as any of you. I have /mnt/cache/appdata/ownCloud as the default in the template.

10 minutes ago, saarg said:

I do not have the same path as any of you. I have /mnt/cache/appdata/ownCloud as the default in the template.

What I'm trying to say is that is what I get in the default template but it should be '/mnt/cache/appdata/config/owncloud/config'.  That is in the default template that is on the repository, not '/mnt/cache/appdata/ownCloud'.  It will work, it's just not the way I intended the mapping to go.  My concern is that the proper template is being used.

2 minutes ago, dlandon said:

What I'm trying to say is that is what I get in the default template but it should be '/mnt/cache/appdata/config/owncloud/config'.  That is in the default template that is on the repository, not '/mnt/cache/appdata/ownCloud'.  It will work, it's just not the way I intended the mapping to go.  My concern is that the proper template is being used.

I updated the template on my repository to fix a formatting issue and that is being picked up by CA properly.  I believe there is something in my template that CA is seeing different than what I intended.  It is changing the appdata mapping form '/mnt/cache/appdata/owncloud/config' to 'mnt/cache/appdata/ownCloud'.

 

Squid, how do I go about tracking this down?  When I test the template in docker, it shows exactly as I intended.

What you're seeing is proper behaviour on dockerMan.

 

The template you've specified is being passed correctly:

  <Config Name="AppData Config Path" Target="/config" Default="" Mode="rw" Description="Container Path: /config" Type="Path" Display="advanced-hide" Required="true" Mask="false">/mnt/cache/appdata/ownCloud/config</Config>

 

Since unRaid 6.2.something, dockerMan automatically adjusts any path that it feels is a /config folder to match the user's system (ie: the default docker config path).  This was implemented because template authors all have a nasty habit of assuming that the path's that they specify in the template for appdata actually matches the user's system.

 

IE: You're explicitly specifying /mnt/cache/appdata/ownCloud/config.

 

Your path is 

• assuming the user has a cache drive
• assuming the user organizes everything into a share named appdata
• assuming that the appdata share is a cache only share (and not prefer or no)

dockerMan is fixing all of those assumptions for the user and substituting the default appdata path/$nameOfContainer instead.  So on my system, I'm seeing as the /config path /mnt/user/appdata/ownCloud.  (even though I have a cache drive)

 

The real problem here is that dockerMan only ever touches the /config mapping automatically.  It is not touching your /data mapping at all, and leaving it with the same assumptions that you're making above.  

 

Why you're able to get it to not do this by adding the template directly via dockerMan, I am not sure, but everything is working as it should be.

 

 

16 hours ago, Squid said:

Doubt it, but doesn't hurt to try.

 

@DZMM  Completely at a loss.  

Fixed.  I had a suspicion that my failed attempts to install 6.4RC2 were the problem, so I did a fresh 6.3.5 install again and all is ok now

2 hours ago, Squid said:

What you're seeing is proper behaviour on dockerMan.

 

The template you've specified is being passed correctly:

 

  <Config Name="AppData Config Path" Target="/config" Default="" Mode="rw" Description="Container Path: /config" Type="Path" Display="advanced-hide" Required="true" Mask="false">/mnt/cache/appdata/ownCloud/config</Config>

 

 

Since unRaid 6.2.something, dockerMan automatically adjusts any path that it feels is a /config folder to match the user's system (ie: the default docker config path).  This was implemented because template authors all have a nasty habit of assuming that the path's that they specify in the template for appdata actually matches the user's system.

 

IE: You're explicitly specifying /mnt/cache/appdata/ownCloud/config.

 

Your path is 

• assuming the user has a cache drive
• assuming the user organizes everything into a share named appdata
• assuming that the appdata share is a cache only share (and not prefer or no)

dockerMan is fixing all of those assumptions for the user and substituting the default appdata path/$nameOfContainer instead.  So on my system, I'm seeing as the /config path /mnt/user/appdata/ownCloud.  (even though I have a cache drive)

 

The real problem here is that dockerMan only ever touches the /config mapping automatically.  It is not touching your /data mapping at all, and leaving it with the same assumptions that you're making above.  

 

Why you're able to get it to not do this by adding the template directly via dockerMan, I am not sure, but everything is working as it should be.

 

 

Is the documented somewhere that I missed?

 

I cloned the ownCloud docker from linuxserver and their original template specified:

Data Path: /mnt/cache/appdata/owncloud/data

AppData Config Path: /mnt/cache/appdata/owncloud/config

 

DockerMan is changing the AppData Confg Path to /mnt/cache/appdata/ownCloud.

 

Now there are two folders in appdata:

appdata/owncloud

appdata/ownCloud

 

This is very problematic in Windows because Windows ignores the case and thinks they are both the same folder.  It is also a messy appdata mapping.

 

I have changed the template to use ownCloud for the data, and DockerMan will do what it insists on the appdata path so at least the mappings a cleaner.

 

I understand why LT did this but I'm not sure it didn't create more problems than it solved.

 

Maybe it would be better to have a template macro to specify the default appdata folder that the docker author could use to keep DockerMan from making assumptions the author doesn't want.

 

For Example:

Data Path: %APPDATA_PATH%/ownCloud/data

AppData Config Path: %APPDATA_PATH%/ownCloud/config

 

I'm not an xml guy, so I don't know if my %...% syntax would work, but you get the idea.  This would make the mapping clean and would not meddle with an author's intended mapping.  Some of us do know what we are doing.  For the docker templates that don't conform, go ahead and make the changes.

1 hour ago, dlandon said:

I understand why LT did this but I'm not sure it didn't create more problems than it solved.

 

Maybe it would be better to have a template macro to specify the default appdata folder that the docker author could use to keep DockerMan from making assumptions the author doesn't want.

I don't know.  The issue is happening because AFAIK this is the only template that is having 2 separate mappings for what is ultimately going to appdata.  There is also nothing stopping you from completely removing the host paths totally from the template and then let the user select where /data goes to.

 

1 hour ago, dlandon said:

Is the documented somewhere that I missed?

 

But the actual implementation isn't exactly how jonp stated, nor did the /unRaid mapped to /mnt ever get implemented

45 minutes ago, Squid said:

But the actual implementation isn't exactly how jonp stated, nor did the /unRaid mapped to /mnt ever get implemented

I've changed my docker templates to be more standard - i.e. default mapping is /mnt/user/...  I guess I missed the memo from jonp.

So I'm working on templating a dockerhub container to make it unRaid-friendly: https://github.com/JustinAiken/unraid-docker-templates/blob/master/bitcoinunlimited/bitcoinunlimited.xml

 

- How's that looking so far

- How do I get it added to CA so it shows up when someone searches "bitcoinunlimited" without having to go to the dockerhub option?

Generally, I'm trying to get away from converted templates, but since it is a unique app in CA, I've added it in.

 

- Expanded the statistics to show what's been deprecated / blacklisted / incompatible

- Big change is that the resource monitor is now removed

 

Resource monitor was 

• A pig on server resources
• A pig on browser resources
• A big kludge in getting it working within the replacement UI
• Looked like crap

 

Installing the cAdvisor application will give the same information (except for appdata size) as CA's resource monitor, and suffers from none of the above problems.  With cAdvisor, the template available in CA is 100% correct, and only requires you to select an appropriate host port.  Don't touch any of the path mappings that are already present.

16 minutes ago, Squid said:

 

- Expanded the statistics to show what's been deprecated / blacklisted / incompatible

- Big change is that the resource monitor is now removed

 

Resource monitor was 

• A pig on server resources
• A pig on browser resources
• A big kludge in getting it working within the replacement UI
• Looked like crap

 

Installing the cAdvisor application will give the same information (except for appdata size) as CA's resource monitor, and suffers from none of the above problems.  With cAdvisor, the template available in CA is 100% correct, and only requires you to select an appropriate host port.  Don't touch any of the path mappings that are already present.

 

Wow, here in the Midwest of the US of A when a man gets to that point, he throws his baseball cap on the ground.  That's serious when that happens!  I think you just did that.

3 minutes ago, dlandon said:

 

Wow, here in the Midwest of the US of A when a man gets to that point, he throws his baseball cap on the ground.  That's serious when that happens!  I think you just did that.

Out of all the components of CA, its the only one that I've hated since day 1.

Just now, Squid said:

Out of all the components of CA, its the only one that I've hated since day 1.

 

I haven't used cAdvisor for a while, but it did a nice job when I used t.  If it's any consolation, I think you made a good choice.

On 6/12/2017 at 4:25 AM, DZMM said:

Fixed.  I had a suspicion that my failed attempts to install 6.4RC2 were the problem, so I did a fresh 6.3.5 install again and all is ok now

 

Have the same issue.  

  

I had a degraded drive in my array, no parity. I put a new drive in, moved files over. During the process the Docker.img got deleted and recreated.  

  

I JUST installed plex, plexpy, binhex-rtorrentvpn, sickrage, using the APPS tab.  

 

But now I'm trying to install Filebot and it wont go past the updating screen.  

  

I had 6.3.4 just updated to 6.3.5 to try and fix the issue to no avail. 

 

Day for the weird "under certain circumstances" fixes that nobody would ever see and/or complain about but were a WTF moment for me when I saw them.

• Fix CSS (on 6.4+) for statistics pop ups
• Fixed: Under certain circumstances previous apps pop ups could display the wrong app
• Fixed: Prevent apps not in appfeed (ie: private apps previously installed, but removed from the private repository) from displaying a popup in previous apps section
• Remove some excess unused code and images
• Remove Sort By Date.  With auto updating apps, its very confusing to see an Last Updated date that's in 2015 because the template hasn't actually changed.  Additionally, removed the Date Updated displaying from docker apps, but left it in place for plugins (since all those guys are very good at updating the template)

Edited June 25, 20179 yr by Squid

Squid: please reinstate Sort By Date, I beg thee. That's the only way I know to check out the latest new apps without the old ones clogging up the view.

 

E.g. if I last checked on 20/06 and found "duplicati" as the newest one, then if I check today 28/06 then I automatically know only to check out apps appearing above "duplicati".

Otherwise without the Sort By Date, the "New / Updated" view has 45 apps, for which perhaps just 2-3 are really new since my last check.

It is very hard to find 2-3 needles in the haystack.

 

And like bags with the missus, there are apps I don't even know I need until I see them - IF I manage to see them.

On 6/28/2017 at 5:27 PM, testdasi said:

Squid: please reinstate Sort By Date, I beg thee. That's the only way I know to check out the latest new apps without the old ones clogging up the view.

 

E.g. if I last checked on 20/06 and found "duplicati" as the newest one, then if I check today 28/06 then I automatically know only to check out apps appearing above "duplicati".

Otherwise without the Sort By Date, the "New / Updated" view has 45 apps, for which perhaps just 2-3 are really new since my last check.

It is very hard to find 2-3 needles in the haystack.

 

And like bags with the missus, there are apps I don't even know I need until I see them - IF I manage to see them.

Ok.  You caught me in an inconsistency.  I left New / Updated which uses the date, but removed the sort by date as authors are terrible at updating the flag.

 

I guess that I've got two choices;

1. Remove the New/Updated Category
2. Reinstate sort by date on New/Updated

 

Probably best if I pick the second option ()   When switching to that section, I'll have it automatically switch to Date Sorted (Descending) which will pop the new apps up to the top of the lists.  But, with the prevalence of auto-updating apps, the docker app guys don't ever change the date updated flag to match the auto update version every Friday at 2300GMT (and I do understand why), I'm going to leave the description / pop up the same as I changed it to on the last release, namely that it won't display the date updated as text, because it's very confusing.  (And at this moment, I can't cherry pick what to display within the various categories.)