Ciao Vieri,
che strano, eppure altre possibilità o ragioni non me ne vengono in mente: comunque la prossima volta nascondi il corso per evitare accessi indesiderati durante l'aggiornamento, non si sa mai .
Per quanto riguarda il bookmarking: da http://pipwerks.com/laboratory/scorm/api-wrapper-javascript/ vedo che pipwerks.SCORM.save() fa una LMSCommit() il che dovrebbe rendere "sempre" persistente il tracciamento, SE ad esempio non hai problemi di rete proprio in quel momento. Potresti provare a testare subito dopo quella chiamata anche pipwerks.SCORM.debug.getCode() per vedere quando ti ritorna l'errore e mandare quindi un alert all'utente in cui gli indichi che per problemi di rete il risultato non è stato salvato. Non risolve ma aiuta se inserisci un po' di informazioni nella finestra di alert e se l'utente ti fa uno screenshot, riesci anche a rimediare intervenendo direttamente su DB.
Per quanto riguarda il tempo: per ragioni credo di performance (ma è da qualche anno che mi chiedo se sia poi così corretta la mia supposizione), il modulo SCORM ha scelto di salvare il cmi.core.session_time nella "sessione PHP" e non è MAI reso persistente su database.
Se l'utente quindi per problemi di rete (o di sessione scaduta perché ad esempio si è preso una lunga pausa con il corso aperto) si perde la LMSFinish() - cioè pipwerks.SCORM.quit() - viene perso il valore di cmi.core.session_time e quindi non sarà mai contabilizzato nella cmi.core.total_time che invece è salvata su database e visibile nei report.
Da tempo vorrei proporre nel main stream una modifica che giudico molto interessante (e già funzionalmente testata e stressata sul campo) per mitigare il problema cioè provare a recuperare il tempo di sessione al lancio successivo (o via cron nelle 24 ore successive) ma non ho ancora trovato quelle ore necessarie per confezionare la patch sulle varie versioni e essere pronto a sostenerla nel Tracker.
HTH,
Matteo