Hi Ron and Dan,

The access date is set for each sco with x.start.time in the beginning of a SCO session (in api.php).
Each time a sco session is started, this value is updated.
But i don't find any usage of this value (x.start.time) to estimate the duration spent in a SCO or anything else.
I think we could modify locallib.php to record this value only once (when the sco is first started)
and never updated it again for the same sco.

This way, the first access date is set upon sco launch and results are accurate.

Valérian

makes sense to me - thanks Valérian! - Ron, I've pushed this into 1.9Stable and Head - could you please test again?

thanks!

Hi Dan and Valerian,

This did not fix the issue. I was able to conduct some testing and found that the record and thus the date is not created until the SCORM LMSCommit is executed. This makes sense since the API is not suppose to send any data back until the LMSCommit is executed. However, this means First Access is not set until that time either.

Can the First Access be set upon SCO launch instead?

Ron

A slight edit to the above. The First Access Date and Time is updated with each LMSCommit until LMSFinish is executed. Then it will remain locked. So what happens is until the SCO sends the LMSFinish and exits the First Access Date is updated.

Hi Ron,

Which Moodle version are you working on ?
I'm on 1.9.8 and x.start.time is set in mod/scorm/api.php (line 85) when this file is loaded by player.php.
The x.start.time value is set as soon as the api is loaded, no matter if LMSCommit, LMSFinish or LMSInitialize is called. This recording of x.start.time is independant from the api.

I've just make some tests, stopping my sco session before any call to the api. The only thing recorded in db is the x.start.time value in the begining of the session and in the report i can see accurate first access and last access date (in this case they are the same).

Hi Valerian,

I am using the latest 1.9Stable branch from CVS.

To conduct the test I opened two browser windows, one signed in as an Admin and the other as a student. This allowed me to check the SCORM report while executing a SCO. The steps to re-create this are:

1. Launch SCO
2. Execute LMSInitialize
3. Check SCORM report - No record of attempt
4. Set core.lesson_status to incomplete
5. Check SCORM report - No record of attempt
6. set core.exit to suspend
7. Check SCORM report - No record of attempt
8. call LMSCommit
9. Check SCORM report - Record of attempt reported with First access time/date stamp equal to time/date of LMSCommit
10. Set session_time
11. call LMSCommit
12. Check SCORM report - First access time/date stamp updated to time/date of second LMSCommit
13. call LMSFinish
14. Exit SCO
15. Check SCORM report - First access time/date stamp updated to time/date of LMSFinish

16. Relaunch SCO
17. call LMSInitialize
18. Check SCORM report - Record not changed
19. Set core.lesson_status to complete
20. Check SCORM report - Record not changed
21. set core.exit to blank
22. Check SCORM report - Record not changed
23. call LMSCommit
24. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit
25. Set session_time
26. call LMSCommit
27. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSCommit
28. call LMSFinish
29. Exit SCO
30. Check SCORM report - First access time/date stamp not changed, Last Access time/date stamp equal to time/date of LMSFinish

Hi Ron,
I'll check this as soon as i can.
Valérain

Hi,

In last revision of the file loaddatamodel.php (for Moodle 2.0), the call to scorm_insert_track has been removed.
With Dan latest backport to 1.9 Stable this call has been removed from api.php (for Moodle 1.9).
That's why the x.start.time value is not recorded on sco launch. In fact, it's never recorded now.

This has been removed in Revision 1.9 of loaddatamodel.php by Piers. Maybe we could reintegrate this ?

Seems like the status of resolved should be reversed as this is not fixed.

weird - not sure what happened there - will fix up after "testing tuesday" is finished.

fix pushed back into 1.9Stable and Head - sorry about that Ron! - can you please re-test and confirm that we've got it right now?

thanks!

Dan