Problemi scorm

Problemi scorm

di Vieri Pestelli -
Numero di risposte: 6

Salve a tutti,

oggi stavo caricando un pacchetto scorm e alla fine dell'operazione dopo aver salvato mi è apparso questo

 

Debug info: Duplicate entry '3355-17-392-1-x.start.time' for key 'mdl_scorscoetrac_usescosco_uix'
UPDATE mdl_scorm_scoes_track SET scoid = ? WHERE scoid = ?
[array (
0 => 392,
1 => '354',
)]
Error code: dmlwriteexception

Stack trace:

    • line 410 of /lib/dml/moodle_database.php: dml_write_exception thrown
    • line 1228 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
    • line 1543 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->set_field_select()
    • line 633 of /mod/scorm/datamodels/scormlib.php: call to moodle_database->set_field()
    • line 240 of /mod/scorm/locallib.php: call to scorm_parse_scorm()
    • line 237 of /mod/scorm/lib.php: call to scorm_parse()
    • line 370 of /course/modedit.php: call to scorm_update_instance()

e mi ha cancellato tutti i dati scorm memorizzati, tipo progresso e tempo di permanenza nel corso (con più di 2000 iscritti).

 

E' un'operazione che ho fatto diverse volte e non mi è mai successo nulla.

 

Qualcuno sa dirmi niente al riguardo!?!

 

Grazie!

Media dei voti:  -
In riposta a Vieri Pestelli

Re: Problemi scorm

di Matteo Scaramuccia -

Ciao Vieri,
innanzitutto non dovresti aver perso i dati di tracciamento: non li vedono i tuoi utenti ne tu li vedi nei report ma - non ne posso però essere certo al 100% - sono ancora nel database, attestati agli ID degli SCO creati nella precedente versione.
Infatti Moodle, quando aggiorni il package, riattesta il tracciamento del corso aggiornato agli LO del nuovo corso che hanno lo stesso item@identifier così come scritto nel file imsmanifest.xml, cancellando poi i dati di tracciamento che non sarebbero più utili perché sono rimasti "orfani".

Se hai seguito la prassi di mantenere gli identificativi nel Manifest identici tra le due versioni (altrimenti il tracciamento lo perderesti "d'ufficio") l'errore sull'indice ha bloccato il processo proprio nella fase terminale, quella di ri-attestazione dei dati dal vecchio ID a quello nuovo:

UPDATE mdl_scorm_scoes_track SET scoid = 392 WHERE scoid = 354

la query che MySQL non ha gradito fa proprio questo, prende i dati di tracciamento del vecchio scoid (354) e li rimappa sul nuovo (392).

Cosa fare ora, tralasciando l'eventuale possibilità di ripristinare il tutto da un backup ragionevolmente recente?
Intanto dipende dal fatto se il tuo package sia multi-SCO: se è single-SCO, allora potresti riprovare ad applicare la query di cui sopra ma probabilmente fallirebbe per la stessa ragione se la causa dell'indice duplicato non sia imputabile ad un temporaneo problema di MySQL. Similmente se fosse multi-SCO ma devi riformulare tu il mappaggio tra i dati precedenti e nuovi.
Anche qui viene in aiuto il fatto che gli ID sono consecutivi per cui se il tuo package è fatto da 4 SCO (lineari, senza gerarchia) e il 392 è il primo allora il ri-mappaggio dovrebbe essere facile:

  • 354 -> 392
  • 355 -> 393
  • 356 -> 394
  • 357 -> 395

Se il package è più complesso (gerarchico) puoi sempre provare a pubblicarlo in un corso privato, annotarti la sequenza degli ID dalla tabella mdl_scorm_scoes, ripubblicare il corso e trovare la giusta logica per il mappaggio manuale.

Devi allora cercare la ragione del conflitto di duplicazione su quell'indice, che garantisce che la quintupla userid-scormid-scoid-attempt-element sia univoca (da qui la possibilità che ci sia stato un temporaneo problema a MySQL durante l'aggiornamento).
Dall'errore (3355-17-392-1-x.start.time) direi che i(l) record incriminato è facilmente individuabile se ci mappi la quintupla di cui sopra: elimina il record con il valore di x.start.time più alto se vuoi conservare la "prima" volta che l'utente ha acceduto.

Quanti altri casi ci possono essere?
Difficile a dirsi, potrebbe essere l'unico (fatale) caso isolato (magari residuo di un update del passato), potresti provare a verificarne il numero con qualcosa del genere - non l'ho testata e potrebbe anche avere impatti sulle performance del DB durante l'esecuzione, provala quindi su una copia del tuo DB! - :

  SELECT userid, scormid, scoid, attempt, element, COUNT(*) c
    FROM mdl_scorm_scoes_track
GROUP BY userid, scormid, scoid, attempt, element
  HAVING c > 1;

Riconosco che la situazione non è delle migliori ma credo ci sia possibilità di recuperare, stante un po' di attento lavoro di fino.

Ovviamente prima di procedere a qualunque manipolazione della tabella dei dati di tracciamento fai un backup del database e se possibile fai tutte le tue prove prima su un DB replicato e poi in produzione, bloccando poi temporaneamente l'accesso agli utenti quando applicherai "la soluzione" in produzione.

HTH,
Matteo

P.S.: di che versioni di Moodle stiamo parlando esattamente?

Media dei voti:  -
In riposta a Matteo Scaramuccia

Re: Problemi scorm

di Vieri Pestelli -

Ciao Matteo! Grazie per la risposta innanzitutto!

Utilizzo moodle 2.3.2,  l'item@identifier è sempre lo stesso, l'unica cosa che è cambiata è l'swf (ma ovviamente non il nome).

La cosa che ti posso dire è che in questa stringa 3355-17-392-1-x.start.time,  392 (lo scormid giusto?) non esiste...

Ultimamente mi dava anche problemi di altro tipo:

il corso è a slide, tutte numerate e con tempo minimo di permanenza, si va avanti e indietro cliccando le relative frecce e nel fare questo si traccia e memorizza il numero di slide e la posizione; alcune volte succede che degli utenti arrivino alla slide 100 per esempio, si disconnettano e quando rilanciano il corso si trovano alla 30 anzichè alla 100 senza un motivo, e dato che su ogni slide ci devi stare almeno 2 minuti rifare da capo cose già fatte a ste condizioni non rende felice l'utente...

Mi è capitato ultimamente di dover caricare e ricaricare più volte il corso, ultima volta ieri quando mi è esploso tutto.

Credi che questi problemi possano essere collegati?

Nel frattempo ripristinero' un backup recente che fortunatamente mi permette di perdere veramente pochissimo, ma il problema è che vorrei capire da cosa dipendono queste problematiche e come fare a prevenirle!

Grazie mille!!

Media dei voti:  -
In riposta a Vieri Pestelli

Re: Problemi scorm

di Matteo Scaramuccia -

Ciao Vieri,
dunque:

  1. per quanto riguarda l'elemento duplicato non lo devi leggere come "stringa" ma come la "select" della seguente quintupla:
    • userid: 3355
    • scormid: 17
    • scoid: 392
    • attempt: 1
    • element: x.start.time
    Controlla e vedrai che ora troverai il record incriminato ammiccante;
  2. Oggi ripensavo a cosa potrebbe essere successo per meglio qualificare l'issue nel Tracker e sono giunto alla seguente conclusione: mentre stavi aggiornando il package e poco dopo che Moodle ha dezippato il corso, l'utente 3355, che ha già frequentato in passato quel corso - scommetto abbastanza recentemente, visto il valore di userid piuttosto alto, utente recentemente iscritto al tuo portale - , è entrato e ha ri-frequentato proprio il corso che stavi aggiornando scrivendo dei dati di tracciamento (x.start.time è la prima cosa che viene scritta quando lancia un LO...) poco prima che Moodle avviasse la ri-attestazione dei vecchi dati di tracciamento. Come verificarlo? Controlla il valore di quel x.start.time convertendolo magari via FROM_UNIXTIME di MySQL o con qualche servizio online, per vedere se la data e l'ora corrispondono all'incirca a quando tu stavi lavorando all'aggiornamento. Se puoi, confermami questa ipotesi così da poter in qualche modo replicare la problematica. Sicuramente nel futuro ti consiglio di procedere all'aggiornamento del package nascondendo l'attività o il corso tutto così che nessuno possa entrare durante la fase di aggiornamento;
  3. Il comportamento del "mancato bookmarking" lo associerei invece alla possibile problematica di portare a termine con successo la LMSFinish() alla chiusura del corso perché se questa non avviene perché ad esempio l'utente stacca la rete prima o il browser "fa i capricci", si perde la persistenza di tutti i dati CMI (tracciamento SCORM) di quella sessione. Dovresti quindi provare a modificare il contenuto perché ogni tanto (non troppo spesso, per evitare di sovraccaricare il server) faccia una LMSCommit() che garantisca la persistenza dei dati registrati fino a quel momento. Prima ovviamente, sincerati della mia ipotesi attivando il debug sul tracciamento, per verificare che la LMSFinish() avvenga proprio alla chiusura dell'attività.

HTH,
Matteo

Media dei voti:  -
In riposta a Matteo Scaramuccia

Re: Problemi scorm

di Vieri Pestelli -

Ciao Matteo,

ti confermo che lo scoid:392 non esiste! Non so cosa possa essere successo...in ogni caso ho risolto alla vecchia maniera ripristinando un backup per fortuna molto recente.

Il problema del mancato bookmarking non me lo spiego perchè nella mia struttura a pagine del corso, vado avanti e indietro con dei pulsanti, e ogni volta che clicco questi pulsanti succede questo:

scorm.set("cmi.core.lesson_location", url);
scorm.set("cmi.core.session_time", tempo_finale);
saveCourseStatus();
scorm.save();


per cui ho un continuo salvataggio dei dati senza dover portare a termine con successo il LMSFInish(). Quello che succede (diciamo una 30ina di casi su 4000 utenti) è che a volte dall'essere arrivati alla scheda50 in una sessione, nella successiva si ritrovano alla scheda1, oppure che dopo 70 schede lette (con tempo minimo di 2/3 minuti di permanenza a scheda...) il tempo tracciato sia 25 secondi!

Ho provato a fare diversi test ma a me non è mai capitato, quindi non so che pesci prendere! Magari fanno azioni che non devono fare,  per questo motivo ho pensato di memorizzare tutto ad ogni singoli click!

Il corso è realizzato in flash con pipwerks.

 

Media dei voti:  -
In riposta a Vieri Pestelli

Re: Problemi scorm

di Matteo Scaramuccia -

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 ammiccante.

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

Media dei voti:  -