Claude's review of swayam plus integration local plugin for Moodle

Created a wiki page at https://github.com/hn-88/swayamplus-sso-api-integration/wiki

and populated it with Claude's comments during its review of code for this plugin which had been generated by Gemini in a single prompt.

Private URL for my reference, https://claude.ai/chat/12096022-e224-4e6b-9e01-40149a93cef7

Google Maps Street View video

Private URL for my reference - https://claude.ai/chat/859a7468-53e7-4e90-96ce-deca9ab6f363

Claude was happy to write code for me when I prompted, "If it is feasible, please write a google apps project which will work with google street view, capturing street view images between two points which the user chooses, and exporting the images as a video journey between the two places on the map similar to what is seen by a dashcam on a car. If not feasible, please suggest alternatives."

But the code requires a project with billing enabled, apparently it does not work with the demo api key provided at https://developers.google.com/maps/demo-key

So, pivoted to making screenshots of the google.com/maps page open in street-view instead - tested using SikuliX IDE 2.0.5 from https://github.com/oculix-org/SikuliX1/releases/download/v2.0.5/sikulixide-2.0.5-linux.jar

Points to note - the delay needs to be more than 5 seconds for me, the images load quite slowly. Alt+Shift+C to abort the SikuliX task.

ffmpeg -framerate 1 -i frame_%04d.png -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2,minterpolate=fps=10:mi_mode=blend" -c:v libx264 -pix_fmt yuv420p journey.mp4

for frame blending, but a timelapse style with more frames per second would probably be needed for longer journeys. The scaling is because the libx264 codec needs even numbered pixel counts for width and height, which may not be guaranteed when choosing a rectangle onscreen.

https://github.com/hn-88/repeated-screen-capture

debugging and testing local Moodle plugin with Claude

Private URL for my reference - https://claude.ai/chat/12096022-e224-4e6b-9e01-40149a93cef7

Used Claude to debug (add missing version.php, and many other omissions) the local plugin for swayamplus api integration generated by Gemini - github repo at https://github.com/hn-88/swayamplus-sso-api-integration. Also added some features like retry logic and test url generation. 

Some points to note:

1. The plugin uses the "Manual enrolment" enrolment method, which is enabled by default on all courses - we can see the enabled methods by going to the relevant course > Participants > Enrolled users (dropdown) > Enrolment methods. 
   
   
2. Guest access should probably be removed from the same place as above, in case enabled earlier.
   
   
3. Currently the classes/privacy/provider.php is not implemented, so the mdl_local_swayamplus_enrol table is not updated by deleting rows if / when users are deleted.
   
   
4. If the user is already present on our system, they are directly enrolled in the course.
   
   
5. If the user is new to our system, the user is dropped into the profile completion and agreement to terms and conditions workflows. Following that, the user is actually enrolled in the course automatically, but dropped into their Profile page. According to Claude, we can add a large link to "My Courses" in the Profile page as follows: 
   1. Go to any page where you can add a block sitewide — the Front Page is the standard choice. Turn editing on.
   2. Add a block → HTML.
   3. Give it a title (e.g. "Continue learning") and content — something like a large, bold link:

      <p style="text-align:center;">  
      <a href="https://ourdomain.org/my/courses.php"     
      style="font-size:1.4em; font-weight:bold; 
      display:inline-block; padding:10px 20px;">
      → Go to My Courses  </a></p>
      

   4. On that block's own settings (gear icon → Configure), under "Where this block appears" → Page contexts, set it to "Display throughout the entire site." Save.
   5. Now navigate to any user's profile page — your own is fine. The block should appear there too (since you just made it sitewide). Open that same block's settings again, and this time change "Display on page types" to "Only user profile pages." Save.

   
   

network problems were due to overheating SFP module

On two consecutive days, internet at the Planetarium went down at around 9 am, working fine before that. The network folks tried sending light down the fiber, it was fine. But the SFP module in the media converter at our end was very hot. They swapped out the media converter, and the network started working again. 

avidemux on Mac - default settings are fine

Verified that with the default settings on Avidemux 2.8.2 compiled for ARM on Mac,

MPEG4 ASP (xvid4) video and AC3 lav audio work for playout on the DVD player, 1920x1080.

For 4K - 3840x2160 - the Videotoolbox HEVC default settings are 2000 bitrate and 4000 max bitrate, which can be increased to 5000 bitrate and 8000 max bitrate to be on par with the settings in python-ffmpeg-warp.

investigating lack of referrals

The Moodle plugin in this previous post was not reporting any referrals for the month of August. Investigating, found that

1. In the new site (swayamplus.education.gov.in redirected from swayam-plus.swayam2.ac.in) login is via email sent to our email id, and my previous email registration doesn't seem to work. Maybe because I had unsubscribed from course alerts?
   
   
2. After logging in with a fresh email, found that swayamplus is no longer adding a referer id to the course URL. There is no &ref=ABC123 part in the URL.

Since they are not sending referral IDs, we cannot report what they don't send!

Moodle server error alert - due to .jpeg extension

One of our Moodle admins reported that

trying to add a content update. I keep getting this error: "servererror,moodle". What could be the problem?

I asked for the URL, and what he had been trying to do. Apparently, the issue was with adding image files with .jpeg extension in a rich-text box. When I renamed the files to .jpg and added them to the box, there was no error. 

creating m3u playlists with Claude

Tried out creating new playlists for playout in Kodi atop LibreElec on Raspberry Pi 4, using Claude instead of manually copy-pasting filenames. Perhaps a time saving of half-an-hour or so? Private URL for my reference at https://claude.ai/chat/cf6e6881-2424-4a24-a1a7-ed38bc9b4942

Uploaded a playlist and prompted

Just like this playlist, please create a playlist called U055newname.m3u where the items #EXTINF:0,1.mp4
 /var/media/1.mp4
 #EXTINF:0,2.mp4
 /var/media/2.mp4
 #EXTINF:0,3.mp4
 /var/media/3.mp4
 are replaced by the files

/var/media/4.mp4
 /var/media/5.mp4
 /var/media/6.mp4
 /var/media/7.mp4

and the appropriate EXTINF lines.

Claude did catch some typos I had made, and double-checked some files, like

Note the last item keeps its .mp4 extension (matching what you specified: only.mp4), unlike the ENG version which was .avi. Let me know if that should also be .avi.

Also asked Claude to create a python script with the prompt

Now, please write a python script to check each m3u file in the current directory if it has all these items as the first few items of the playlist,

(lines of playlist pasted here)

(for playlists which have TEL in the name)

and if any items are missing, to add them in this order.

Similarly, for m3u files with 3lang or ENG in the name, 

(lines of playlist pasted here)

and for playlists with HIN in the name, 

(lines of playlist pasted here)

which worked well - I have uploaded to the private repo upstairs-Kodi-playlists

dotnet api timeouts and action taken

The developers on one of our apps noted that 

The API is intermittently failing, and we are seeing a CORS error in the browser Network tab.

Claude noted that the CORS error is misleading, and it is probably because of a backend API timeout. 

this is almost never an actual CORS policy misconfiguration — it's the browser's error message for "the actual response didn't carry an Access-Control-Allow-Origin header," which happens whenever the request fails or errors out before your CORS middleware gets a chance to run. Since it's intermittent, that's your biggest clue.

Since a lot of bot traffic was seen looking for Wordpress files, they requested blocking those bots which look for non-existent Wordpress files.

Taking Gemini's advice, 

1. Disabled php on the api server, since it's not required by our services - 

sudo a2dismod php8.3

sudo systemctl restart apache2

2. Added one more firewall rule to Cloudflare, the URL being like

ourdomain.org/security/security-rules

(http.host contains "ourdomainname" and http.request.uri.path contains "wp-") or (http.host contains "ourdomainname" and http.request.uri.path contains ".php")

then Block