[QUOTE=marigonzes;453890]Just found another issue:

If I type a wrong Username/Password combination, the site takes me to a 404 page.[/QUOTE]

Oh... that's probably because of the https change. I kind of cheated and did a search/replace for things to make self references protocol relative but that's not quite working right for the failed login case. Thanks for spotting that.

[QUOTE=Madpoo;453910]I kind of cheated and did a search/replace for things to make self references protocol relative but that's not quite working right for the failed login case. Thanks for spotting that.[/QUOTE]

There's an old saying... No good deed goes unpunished.

Thank you! :smile:

[QUOTE=Madpoo;453907]I have every reason to believe your issue is due to your unique circumstances.

You have 2 cpus with assignments... one of them only has 4 active assignments while the other has 710,618 assignments.

Part of that little table does an average age of all your assignments which it does by using the SQL avg() function for the difference in minutes between date assigned and now, divided by 1440.0 (to show the average diff in days to a precision of x.xx).

Your particular issue is that it's easily overflowing the ability of SQL to average an int over that many rows (int is the default cast for datediff, I'm guessing).

I'm questioning the usefulness of showing the average assignment age for that many (or even at all). It seems of questionable utility...

I could cast the datediff to bigint before inside avg() ... your average TF assignment age (of which there are 710,606 right now) is 36.88 days. Does that help you in any way? LOL[/QUOTE]

No, I'm not interested in the average assignment age either. LOL... I actually just want to know the number of current assignments for each type.

Your explanation also matches my observations where the error suddenly showed up and didn't go away for some weeks and then again for some days everything was fine before it happened again.

BTW, the 7xxxxx assignments of the second "cpu" are those from manual testing. And the reason why they are so many is mainly because the [URL="https://www.mersenne.org/manual_gpu_assignment/"]manual GPU assignment page[/URL] ignores the requested bit level to factor to and sets it considerably higher (e.g. 74 instead of the requested 70). As I TF them only to 70 (as intended) they are waiting to expire (should happen soon).

[QUOTE=ramgeis;453962]No, I'm not interested in the average assignment age either. LOL... I actually just want to know the number of current assignments for each type.

Your explanation also matches my observations where the error suddenly showed up and didn't go away for some weeks and then again for some days everything was fine before it happened again.

BTW, the 7xxxxx assignments of the second "cpu" are those from manual testing. And the reason why they are so many is mainly because the [URL="https://www.mersenne.org/manual_gpu_assignment/"]manual GPU assignment page[/URL] ignores the requested bit level to factor to and sets it considerably higher (e.g. 74 instead of the requested 70). As I TF them only to 70 (as intended) they are waiting to expire (should happen soon).[/QUOTE]

I fixed it to use my "cast to bigint" method since it still seemed to run pretty fast, even for that many assignments. It should work for you now.

As for the manual GPU assignments not honoring the requested bit level, I'll leave that to smarter minds than me for a potential fix, unless I find myself with some time to mull that over this coming weekend. That page is specific to GPUs and I don't really know much about it except it's a stripped down/streamlined page so that getting bulk work isn't loading a bunch of other stuff that a bot doesn't care about.

[QUOTE=marigonzes;453876]If I go to [url]https://www.mersenne.org/cpus/[/url] while logged in, check the "I am sure I know what I am doing" checkbox and then click either "Merge checked CPUs" or "Drop checked CPUs", I get the following error:[/QUOTE]

Question: Did you actually check two or more computers from your list to merge?

I can get the same error if I check the box "I know what I am doing" and click merge, but didn't have any computers marked to merge.

There should be some error checking there to make sure the user actually picked something and show a message to that effect (and it could be said that if you forgot to check computers to merge and click that button anyway, you really didn't know what you were doing and shouldn't have ticked that box :smile: )

I'll see if I can't work in a warning if you didn't tick a couple computers to merge. The error comes up when looking up the id of the most recent computer from the list you selected... I think there may not be any harm done if you only picked one computer to "merge" (it just wouldn't effectively do anything), but definitely two or more make the most sense, and zero selections is patently bad.

[QUOTE=ramgeis;453962]
BTW, the 7xxxxx assignments of the second "cpu" are those from manual testing. And the reason why they are so many is mainly because the [URL="https://www.mersenne.org/manual_gpu_assignment/"]manual GPU assignment page[/URL] ignores the requested bit level to factor to and sets it considerably higher (e.g. 74 instead of the requested 70). As I TF them only to 70 (as intended) they are waiting to expire (should happen soon).[/QUOTE]

I cannot get any assignments with 70 as the bit level. What other settings are you using on that web page?

[QUOTE=ramgeis;453962] ignores the requested bit level to factor to and sets it considerably higher (e.g. 74 instead of the requested 70). As I TF them only to 70 (as intended) they are waiting to expire (should happen soon).[/QUOTE]

The results of that page shows 74, but your assignments page shows the correct bit level in the worktodo.txt section.

[QUOTE=Prime95;453999]I cannot get any assignments with 70 as the bit level. What other settings are you using on that web page?[/QUOTE]

If for example I choose

Number of assignments you want: 1
Preferred work range: TF for 100M digits Mersenne numbers
Optional exponent range: 900000000 to 999999999
Work preference: Highest exponents
Optional bit level to factor to: 70

I get something like

Factor=0BAC9681252C83C97BEC49A41436E3DB,979868807,69,74

which is not what I wanted. The resulting URL is

[URL]https://www.mersenne.org/manual_gpu_assignment/?num_to_get=1&ghz_to_get=&pref=4&exp_lo=900000000&exp_hi=999999999&pref2=5&factor_to=70[/URL]

[QUOTE=0PolarBearsHere;454025]The results of that page shows 74, but your assignments page shows the correct bit level in the worktodo.txt section.[/QUOTE]

The server still insists that those exponents are assigned to me, presumably as I did not TF to 74 (only to 70). For example:

[URL]https://www.mersenne.org/report_exponent/?exp_lo=868829719&exp_hi=&full=1[/URL]

They will expire in 3 days anyway...

Madpoo, when I got the error for clicking the button to merge, I didn't have any computer selected. When selecting one or more computers, it works fine for me.

Thanks

[QUOTE=ramgeis;454030]The server still insists that those exponents are assigned to me, presumably as I did not TF to 74 (only to 70). For example:

[URL]https://www.mersenne.org/report_exponent/?exp_lo=868829719&exp_hi=&full=1[/URL]

They will expire in 3 days anyway...[/QUOTE]

The script I use to get my assignments scraps the manual gpu assignment page and then changes the bit level in the downloaded assignment to what ever I've specified it to (i.e. from 74 ->69).
I don't get the same issue that you do (for example [url]https://www.mersenne.org/report_exponent/?exp_lo=978585631&full=1[/url] ) so something funky is definitely going on.