This applies to a Samsung Micro SDXC xGB EVO Memory Card that I recently purchased (and probably a wider range of similar Samsung cards). Despite a long search, I couldn’t find any information (even on Samsung.com) about which of the tiny sets of numbers and letters on the back of the card constituted the serial number.
I’ve finally figured it all out. On the back of the card, there are 4 lines of information. From top to bottom as it relates to the sample image:
Line 1 is the Model Number > MB-MP32D (the 32 signifies 32 GB, in this case)
Line 2 is the Lot ID > MBMPBGVEQBFW-B
Line 3 is the Serial Number > DHTA410GG407
Line 4 is the Country of Manufacture > MADE IN KOREA
EDIT: Based on a comment posted by KK, MAY 18, 2017 AT 1:10 PM, I’ve reviewed the product packaging. KK was advised by Samsung Canada Customer Support that the serial number is not on the memory card and is, instead, on the product packaging. I happen to still have the replacement card that Samsung provided under warranty in the original packaging. Unfortunately for this agent at Samsung Canada support, there is no evidence of a serial number anywhere on the outside of the packaging. Upon opening the blister pack, I found no numbers on the inside of the packaging, either.
The first task is to verify if you have a WNDR3400 V1, 2, or 3. I used this site to determine I have a V1 device. As the hardware for each version is significantly different, this procedure ONLY applies to V1.
According to what I found here (Sat Jun 11, 2016 4:06 post by mrjcd), the latest known good version of dd-wrt for this router is v24-27858_NEWD-2_K2.6. When going from stock firmware (as I am), use dd-wrt.v24-27858_NEWD-2_K2.6_mini-WNDR3400.chk.
- Reset the router
- Connect via Ethernet cable to the router’s #1 port
- Access the firmware update page at http://192.168.1.1 using the default admin/password login
- Upload the dd-wrt firmware
- Wait for the firmware to upload and for the router to restart
- Access the default dd-wrt Router Management page at http://192.168.1.1
Additional Reference: The infamous “Peacock Thread”
Perhaps the single biggest hamartia of the Barracuda Spam Firewall’s Attachment Filtering is that it omits filtering any whitelisted messages. Based on this comment in the user forum, this has apparently been an issue for at least 9 years.
To review your Attachment Filename Filters (only visible when managing the overall system): BLOCK/ACCEPT > Attachment Filters
If you are interested in changing this behavior, you should add your name to Feature Request ID BNSF-8261.
When using the Print button embedded in a ticket, I receive the following error:
The website encountered an error while retrieving https://<my server’s path>/tickets.php?id=274&a=print¬es=1. It may be down for maintenance or configured incorrectly.
The root cause was evident when reviewing /var/log/httpd/user-error_log:
FastCGI: server “/php-fpm-handler” stderr: PHP message: PHP Fatal error: Unsupported operand types in /volume1/web/osticket/upload/include/mpdf/config_fonts.php on line 307, referer: https://<my server’s path>/tickets.php?id=274
The resolution is to enable PHAR
Go to Control Panel > Web Services > PHP Settings > Select PHP extension
Then select “phar” and click ok.
Beginning with IBM Traveler 18.104.22.168, the NTS_DEFRAG_INTERVAL_DAYS= ini setting is no longer valid.
If the setting is still present in the Traveler server’s ini, you will see the following warning on the server console (and/or in the log) when Traveler starts:
Traveler: WARNING *system Unrecognized IBM Traveler parameter in notes.ini: NTS_DEFRAG_INTERVAL_DAYS
If the server was upgraded with the NTS_DEFRAG_INTERVAL_DAYS= in place, the upgrade process appears to transfer the previously set interval. The same result can be achieved by issuing: tell traveler dbmaint set interval 30
You can then verify the set interval using: tell traveler dbmaint show
Don’t forget to remove the NTS_DEFRAG_INTERVAL_DAYS= setting from your post-22.214.171.124 server’s ini.
In a standalone DB situation where you want to trigger Traveler database maintenance, you can issue the following command at the console: tell traveler DBMaint run
This will set the ini parameter NTS_DEFRAG_ONCE=1 which will trigger defrag at the next Traveler restart. The server will automatically remove the NTS_DEFRAG_ONCE=1 setting after the triggered defrag completes.
Again, in a standalone DB situation, you could automate regularly scheduled defrags to run by:
- Using the “tell traveler DBMaint set” commands to set the desired interval, time, day
- Creating a Program document that issues the server command, restart task traveler, just after the time set in the command above
Those that are already using or considering enabling secure SMTP sessions using STARTTLS for Domino should either disable it / wait for now (until SPR# MKENA4SQ7R is resolved in an IF or 9.0.1 FP6), obtain hotfix(es) directly from IBM, or risk the inability to deliver/receive TLS with (at least) some @outlook.com addresses.
For those using (or planning to use) TLS, you should also look at adding the SSL_SESSION_SIZE notes.ini setting. When the setting is not used, the value defaults to 5000 and this is too low to prevent errors like:
02/25/2016 12:23:52 PM New SSL session data length of 5121 bytes is larger than the current size of 5000 bytes.
02/25/2016 12:23:52 PM You may want to set the Notes.ini variable SSL_SESSION_SIZE to at least 5121 bytes.
Note that the server suggested the 5121 value in this example (presumably based upon the handshake with the external server) and I’ve been unable, as yet, to find any other scientific method for determining what other value might be better.
I recently encountered an issue where my Logitech Harmony 650 Remote sync hung at 99%. I found a few other users mention the same issue in the support forum and found that I was able to get past the issue by continually pressing the center button (a.k.a the “OK” button) beginning at around 95%. Although the remote goes into safe mode, the sync process successfully completes at 100%. I then close the sync as normal and remove the batteries from the remote to get back out of safe mode.