Seems to have been completed this morning. Any progress yet on what is causing the initial problem?
This week the process (whichever is at fault) has stopped in the middle of doing route 8, thus slightly further than last week’s first effort.
If it went on a bit further so as to go “99, bonk” I could at least resurrect the centipede joke from my schooldays.
The missing stuff completed this morning.
One point worth noting. Since the upload moved to Sunday, we only get the Sa and Su WTTs were there has been a service change, the MF following the next weekend. The 142 and 187 are just two of the examples this week. It is not universal as (for example) all files for the 218 and 226 are present.
The logic (for the 142 etc.) would seem to be that a new WTT should only be uploaded once it has actually been operated (which on the Sunday it would not have been). For the 218 etc. it would seem to be that a new WTT should be uploaded once the WTT it is replacing has gone dead (which an obsolescent MF schedule would have done by Sunday). Not sure why it varies (different operators?) but clearly the second (218 style) approach is better for the user.
I also note that five files dated 28/01/2023 have been loaded (routes 35 and 176). Either they are dated wrongly or they (or at least the 176 files; the 35 is a “special”) have prematurely overwritten the current files. So that is a third variant of timetabling updates!
@mjcarchive I’ve been informed by the support team that they have deployed a change for a related issue and have asked if we can check over the next few days to see if that has resolved our issue. I’ll be checking the number of files transferred in total over the next few days to see if there has been any improvement.
Thanks. “Related issues” always pique my interest! It’s usually the case that the error you see from a computer system is a symptom of a bug several thousand lines of code earlier…
Fingers crossed for Sunday.
Alas, same old, same old. It stopped after Schedule_9-spFr.pdf and before Schedule_9-spSa.pdf.
Completed OK this morning
Only made is part way route 7 this morning.
… and completed this morning. Any ideas yet? I don’t think it can be a limit on the number of WTTs that can be handled as there are scarcely any more this week than last but it didn’t get anywhere near as far. A limit on the overall number of files that can be bucketed? Seems unlikely.
Do we even know whether it is the file creation or the file uploading aspect which is crashing?
Whatever the cause, it’s a pain!
@mjcarchive still under investigation I’m afraid. it feels like there is a pattern here where only some files are pushed through on sunday morning and the rest are pushed through the next morning. would you agree?
Absolutely - I thought I had been saying that for weeks!
Thinking about it, given that the entire set is supposed to be updated in one go, the fact that it picks up the next morning where it left off rather than starting from scratch (and failing again) is quite interesting, as it suggests that the rest of the job has been left queued for the next overnight window. In the interests of ruling out the simplest explanations first, is that window perhaps too short to enable the Sunday morning upload to complete? (The even simpler explanation, that it will only do up to N files, does not seem to fit the evidence.)
It got as far as finishing B13 this morning.
Shame, as I’ve only got numbers on my WTT bingo card!
The non-updated WTTs have now been updated…
And in the case of the B13, the map on the TfL website still seems to be trying to show it going to the old terminus (see my other post)
Got up to B12 this morning before stopping.
Do we know whether the files are not being created at all or just not uploaded to the right location?
Whatever is happening, it is getting rather tedious.
Everything was hunky dory on Monday morning.
I want to bump an issue I highlighted some months back. If you look at page 11 of
you will find that the top of the page has two rows jostling for the same space. Closer inspection shows that the fainter row contains the data for trip 172, which is should be at the foot of the page.
This is uncommon but does affect at least one page on 3 of the new schedules for route 5. Route 365 shows something similar and I think there may be one or two more I cannot recall.
It is not clear from this, of course, whether the error has crept in in the process of creating the PDF file, or whether it is already there in the underlying source.
It fell over in the middle of doing the N133 this morning.
Update completed this morning.
I appreciate that there are more important things to sort out but has understanding progressed?
@mjcarchive unfortunately nothing yet. the issue is still under investigation by the external supplier and their Adiona team.
Crashed after N22 this time.
Ah well, I would have been busy with other stuff today anyway.