MAINTENANCE SIGNATURE FOR SMARTSHARE V2.0.13
Incident Properties
Question
Hello,
We would like to ask for a maintenance signature for Smartshare Android embedded solution.
- stability improvements and error handling
King regards
Anderson
Compatibility Testing - AAA
Incident Properties
Question
Just wanted to check if there are regional validation limitations? We're presuming that our app, once validated can be installed on any device worldwide?
Thanks.
Test Unassigned Incident - For testing purposes only - do not process!
Incident Properties
Question
test stuff
Test Assigned Incident - For testing purposes only - do not process!
Incident Properties
Question
stuff and things
MAINTENANCE SIGNATURE FOR SMARTSHARE V2.0.12
Incident Properties
Question
Hello,
We would like to ask for a maintenance signature for Smartshare Android embedded solution.
- stability improvements and bug fixes
King regards
Anderson
MAINTENANCE SIGNATURE FOR SMARTSHARE V2.0.11
Incident Properties
Question
Hello,
We would like to ask for a maintenance signature for Smartshare Android embedded solution.
- stability improvements and bug fixes
King regards
Anderson
How to enable card swipes from sleep
Incident Properties
Question
Hi RIDP,
We had some discussions about enabling card swipes from sleep (swipe to wakeup and login). We have implemented this as mentioned in this Ricoh ticket https://ricoh-ridp.com/ridp/support-system/incident/ricoh-americas-corp-technology-center/1515115084/1268767928/2400 that suggests to keep the PANEL_STATE set to 2(sleep)
“Please use Lock Panel Display State API (@see the attached file). Application can reject panel power mode to going to Sleep mode by using this function. This MFP behavior from lock panel display state(sleep) until unlock panel display state is same as "Screen Device always connection" mode.”
We also go the following instruction from you
https://ricoh-ridp.com/ridp/faqs/should-i-turn-screen-device-always-connection-setting-support-usb-swipe-and-wake-device: This RIDP article suggests that we implement a lock for the display state from our application. It seems to accomplish the same thing, to prevent the panel from going into the SLEEP state, but either way, it is better because we could implement this without a Ricoh tech visit.
I cannot access the above link with my RIDP account, Can you fix that?
Can you also see below and confirm that we are doing the correct thing to achieve "swipe from sleep" ?
- If the card reader is attached, send the intent "jp. co. ricoh. isdk. sdkservice. panel. LOCK_PANEL_STATE" with PANEL_STATE = 2
- Keep it locked during the operation as long as the card reader is attached.
- Unlock it once the reader is detached
- Always check on reboot if a reader is attached, if yes, lock the panel state as above
We found that this approach works in general. But we want to check with you if anything else is to be done.
Thanks.
Incident Report – PullPrint Job Skipped (STATE_JOB_PENDING → STATE_JOB_COMPLETED Without Processing)
Incident Properties
Question
Dear Ricoh Support Team,
We are experiencing a critical issue with the PullPrint function in our Ricoh SOP application. The printing function suddenly stopped working for all PullPrint jobs. Below is a detailed report of the behavior and findings:
Issue Summary
-
PullPrint jobs are not being printed.
-
The job transitions directly from
STATE_JOB_PENDINGtoSTATE_JOB_COMPLETEDwithout entering theSTATE_JOB_PROCESSINGstate. -
No output is observed from the printer, despite a successful job lifecycle from the API/log perspective.
Device Behavior Observed
-
Scanning and copying operations work correctly.
-
Printing from the Ricoh built-in Print App (non-PullPrint) works as expected.
-
Only PullPrint jobs are affected.
Log Evidence
less
CopyEdit
08-06 15:31:41.444 I/UPConnector: service:PrintStMcn:#evtp :CHANGE_JOB_STATE_COMPLETED state:STATE_JOB_PENDING > STATE_JOB_COMPLETED
Documentation Insight
As per the Ricoh Developer Guide:
"Pending → Completed" transition may occur if the "pull (obtain file)" operation is not completed normally.
Additional Notes
-
The files being printed are previously tested and have worked multiple times — URL and file validity is not in question.
-
The issue began suddenly, without any updates or configuration changes on our side.
-
We're not using any custom authentication.
-
Multiple different PullPrint jobs (files) have been tested — all show the same issue.
Request for Support
We kindly request your help to:
-
Identify what could cause this behavior in PullPrint.
-
Provide any logs or diagnostic steps we should collect to assist further.
-
Confirm if this is a known issue or firmware-level behavior change.
Please advise on the next steps at your earliest convenience.
Maintenance signature request for PaperCut MF v3.2.11
Incident Properties
Question
Hi,
Please find attached version 3.2.11 of the PaperCut MF application for a maintenance signature.
The changes are described as follows:
- Fixed an issue where it caused application to crash when using advanced scan
Thanks
Support for Multiple PIDs During Fast Bootloader Re-enumeration in RfIdeasPlugin
Incident Properties
Question
HI Team,
We are enhancing our RfIdeasPlugin(1667760129) by adding support for Fast Bootloader to significantly reduce the firmware update time. This process involves transmitting data in 4KB chunks for faster performance.
As part of the Fast Bootloading sequence, we re-enumerate the reader's PID to 1. The steps involved are as follows:
1. Connect the reader with the correct initial PID (e.g., 3BFA)
2. Verify if the reader supports Fast Bootloader
3. Re-enumerate the reader’s PID to 1
4. Disconnect the reader
5. Wait for 3 seconds
6. Detect the reader with the new PID (1)
7. Re-scan and re-establish the connection
At step 7, I’m facing an issue while attempting to claim the reader connection.
Scenario:
When the plugin is deployed, the printer registers the reader’s current VID and PID. However, after re-enumeration, the reader’s PID changes. As a result, the printer no longer recognizes the updated PID, causing the plugin to crash with the error message “RfIDEASPlugin keeps stopping” (refer to Image 1). This ultimately leads to a failed connection attempt.
This issue seems to be caused by a mismatch between the VID/PID registered by the printer (3BFA, as shown in Image 2) and the reader's PID (0001) after re-enumeration.
I reviewed the SmartSDK documentation but couldn’t find any reference to support for multiple PIDs—other than adding entries to the Program Device List, which unfortunately does not resolve the issue in my case.
Could you please advise if the printer can be configured to support multiple PIDs?
Alternatively, is there a way to bypass the “RfIDEASPlugin keeps stopping” issue so that I can continue with the firmware update process?
Any suggestions or alternative approaches to handle this scenario would be greatly appreciated.
Looking forward to your guidance.
Thanks.