Manual reporting of two-line "known_factors" PRP results is broken right now:

Notice: Undefined index: known_factors in C:\inetpub\www\manual_result\manual_result.inc.php on line 361
processing: PRP=(false) for M[M]3996653[/M]
Notice: Undefined index: known_factors in C:\inetpub\www\manual_result\manual_result.inc.php on line 372 Notice: Undefined index: shift_count in C:\inetpub\www\manual_result\manual_result.inc.php on line 379 Notice: Undefined index: error_code in C:\inetpub\www\manual_result\manual_result.inc.php on line 379
Error code: 40, error text: No CPU credit given for test of already factored M[M]3996653[/M]

Contrary to the error message, no previous PRP result has been reported for this exponent.

Manual reporting of one-line PRP results also seems to be broken the same way, except without the "line 372" error, just line 361 and 379.

Automated reporting to Primenet of one-line PRP results is still working, though.

[QUOTE=GP2;469181]Manual reporting of two-line "known_factors" PRP results is broken right now:
Notice: Undefined index: known_factors in manual_result\manual_result.inc.php on line 361
[/QUOTE]Silly me, I changed two files and only uploaded one of them. :redface:
As a test case I submitted
[url=https://www.mersenne.org/M19571]M19571[/url]/6353725151/2844272257303/44693616409729050616105544862466390529
So that has been (incorrectly) credited to me, sorry. And if you may get an unexpected not-needed result if you try to resubmit it.

But the manual form should be working again for PRP.

[QUOTE=Prime95;469104]Odd. There were 2 incorrect entries in the app_versions table. I fixed the problem so it shouldn't happen in the future, but I did not go back and mark DC'ed PRPs as not DC'ed.[/QUOTE]

I think it would be OK to mark the exponents that were DC'ed with the same shift count of zero as not DC'ed. Probably there are only a relatively small number, and nearly all of them in the smaller exponent ranges like 1.6M and below, where each exponent can be PRP tested in a matter of minutes.

Server - PHP upgrade
 

Hi all... the server got an upgrade to the PHP version last night. Big swap from 5.6 to the latest 7.1 so there were some changes to code to handle a few deprecated things that are now gone, and other quirks.

I chased down some old v4 client problems this morning and hopefully those old clients are checking in smoothly again. Few other minor glitches here and there but I think I'm top of them.

If anyone does encounter *new* strange things (if it was strange before, don't bug me about it, LOL) just let me know. I'm working backwards from any errors PHP is throwing but there could be things happening that aren't an error, just acting different than it used to. Probably not, but just in case...

[QUOTE=Madpoo;469354]Hi all... the server got an upgrade to the PHP version last night. Big swap from 5.6 to the latest 7.1 so there were some changes to code to handle a few deprecated things that are now gone, and other quirks.
[/quote]

You should see a noticeable CPU reduction from that.

[quote]I chased down some old v4 client problems this morning and hopefully those old clients are checking in smoothly again. Few other minor glitches here and there but I think I'm top of them.[/quote]

Wasn't there only that one machine left?

[QUOTE=Mark Rose;469363](re: v4 clients) Wasn't there only that one machine left?[/QUOTE]

There are actually a few. Kinda scratching my head on why they're still running v26 or earlier clients, but oh well. The server has the support for those still so... whatever floats their boat.

I don't know if they'd benefit from newer versions since I don't know what kind of CPUs they're using (or maybe they're still on 32-bit OS?)

[QUOTE=Madpoo;469369]There are actually a few.[/QUOTE]

It seems like there's only one still returning LL results though, maybe the others are factoring?

[QUOTE=GP2;469371]It seems like there's only one still returning LL results though, maybe the others are factoring?[/QUOTE]

Could be. I didn't see what they were reporting, just that they're coming from a few different places.

I did notice some of them are also still trying to hit the old Perl page that I think showed user stats or something (primenet_report.pl or something like that). It no longer exists, they're getting 404's trying to hit it, but still they keep trying.

"Work Results Details" page
 

I do appreciate the new information given by the "Work Results Details" page : having the B1, B2 and E values for PM-1 results on that page is very nice.

I regret one thing though : when some data in the "Result" column is too long the "Result Type" and "Received" columns get wrapped.Which means every single row is two lines high I would prefer to have only the data in the "Result" column to be wrapped : it would only affect those rows that have a long content in "the "Results" column.

Jacob

www.mersenne.org timeout
 

[URL]https://www.mersenne.org/[/URL] -> no longer reachable (timeout) :no::no:

EDIT: seems ok now. Was offline for 10-15 minutes I guess.

Reporting a factor manually gives me this error message at the moment:
[QUOTE]Notice: Undefined variable: current_factor_prime in C:\inetpub\www\manual_result\manual_result.inc.php on line 247 IsAuthenticMersenneFactor(): Unexpected value for factor: [/QUOTE]
All following lines are ignored. Reporting just no-factor-found lines works fine.