Subj : Re: Miss.RvrDamBreach-Davenpt To : Barry Martin From : Nancy Backus Date : Tue Sep 10 2019 01:02:40 -=> Quoting Barry Martin to Nancy Backus on 04-Sep-2019 09:12 <=- Continuing at the Pond on 9 Sept, at just after 9pm... NB>>>> And now soon to return, to find your deluge to answer.... ;) BM>>> The good news is I did break up the replies into smaller BM>>> chunks, mainly to not potentially overload my side, but also good BM>>> stopping points. NB>>> When I got back, I did tailor my packets a little... I was able to NB>>> put the echoes from Tiny's that I would have messages in to reply to NB>>> into one packet, and all the rest into another one... made the one NB>>> to answer a little more wieldy than it would have been otherwise... NB>>> Of course, I wasn't gone for a month.... :) BM>> No, just a fraction of a month. :) NB>> Make that fractionS of a month... BM> True, as multiple. Exactly... a week in June, 2 different weeks in July, almost a week in August, and now a long weekend in September... And coming up, about a week at the end of September, and another long weekend in October... Definitely multiple.... BM>> It was easier for me to download all and work on it a little at a BM>> time. Pretty sure I have a maximum packet size set somewhere -- has BM>> been a while since fiddled with those settings. NB>> I'm sure I have maximum packet size set on each of the bbses, but NB>> generally what would work best for actually reading/answering NB>> them is much smaller than that default... It's way too easy to NB>> overwhelm this computer with a huge packet... It needs more than NB>> double (maybe triple?) the space to open it, and more headspace NB>> to close it again... And I tend to not really have a lot of room NB>> available at a time... BM> Right. I vaguely recall there is a time when there are two files in BM> memory, before gets written to a temp file on the hard drive. Yup, something like that... NB>>> Oh, they are... and that's also why I don't get myself stressed out NB>>> when it takes a while to plod thru them all... ;) If I get the last NB>>> 6 to you from this packet answered tonight, I'll be able to tuck this NB>>> packet away... and continue on to the ones that are more recent... :) BM>> Yup: seemed a little funny to read of 4th of July in the earlier BM>> message with Labor Day coming up in a few days. NB>> Really stretched out threads.... BM> Think we need to get steel bands to reinforce?! Nah... just need to get them more to size again... :) NB>>>> He'll have a more robust piece of software, you'll have a nice NB>>>> working utility.... :) BM>>> True, though on my end the utility is a one-function one: the source BM>>> and destination, file locations, etc., are hard-coded into the BM>>> software, though I think written in Python so would just need to use a BM>>> text editor to update. I only vaguely understand so at this point BM>>> easier to leave all corrections up to him -- plus if I make a change BM>>> isn't in the 'master' for eventual distribution. NB>>> One-function utilities aren't all that bad a thing... as long as NB>>> they perform a function that you need to have done.... :) BM>> Yes, though for this utility it would seem to make more sense to have BM>> a configuration while the user would edit instead of editing the actual BM>> programme file. Essentially the same as the configuration file BM>> modifies the programme file, just I prefer not fiddling with the BM>> master. NB>> Maybe you should suggest that to him.... or do the actual work NB>> with an iteration of the program, not the original one...? BM> I'll have to look to see how the executable files I was working with BM> were done -- IIRC most are on Backend 2 and that was shut down. Seems BM> easy enough to create a master configuration file; the trick is to BM> have the script file look at it and pull the information! So now you just have to figure out how to make that work... :) BM>>> I'll admit to being amazed at the details, forethought, etc. Possibly BM>>> due to 'oh poop!' events that happened years ago when he first started BM>>> creating this set of utilities , but still. NB>>> Good that he is able to figure it all out... :) BM>> LIS I think he's one of the developers though never stated anywhere BM>> and didn't make any difference - he knew the stuff was what mattered. NB>> Yup, either way, he's developing it now, too... and knows what's NB>> going on with it... ;) BM> Or at least the 'transfer utility' portion of it. ...Now getting more BM> curious as to how it's all done! While I was working with him I was BM> more interested in reporting the results, detailing what went wrong so BM> he could correct -- basically I was his eyes and there were more than a BM> few times "something's wrong" but I didn't know exactly what to report BM> to give the information on how to fix so he got too much information. So understanding it might make reporting bugs better/easier.... :) BM>> BTW, the transferred files (from old system to new) work fine. The BM>> old Backend has been powered off for some time -- maybe only a week but BM>> seems longer! Still have to move the hardware around -- the new BM>> Backend is still on the floor and needs to be moved to the cabinet, but BM>> first need to make room on/in the cabinet.... NB>> Eventually... ;) BM> In the mean time..... Other things pop up and need doing.... :) BM>>> And it does work: just before I left I done some testing with larger BM>>> chunks: move over all shows from Channel 8_3, for instance. (The file BM>>> names have the channel included.) Couple of 'specific channel' tests, BM>>> passed. Got 'brave' and tried copying over the remainder: only real BM>>> difference was instead of a batch of maybe twenty or thirty files was BM>>> over a hundred files. Passed. :) NB>>> Hurrah for that! And no doubt a major relief when it did pass... ;) BM>> Yes. There's always the "it works on x-system but will it work on BM>> y-system?". He has (IIRC) 12 TB of storage, I 'only' 4 TB. And both BM>> of those numbers are 'wrong' as we really need to be looking at free BM>> space. For a short while I was using about half, so 2 TB. And the way BM>> the transfer utility worked is it only bit off small chunks: a single BM>> TV programme at a time, so usually no more than 2 GB; select, process, BM>> move over; select, process, move over.... NB>> You have WAY more capacity than I have... ;) But the important NB>> thing is that you do have what you need to do the job at hand... :) BM> And DOS won't handle that amount anyway. Well, could partition a BM> multi-terabyte drive. Don't think that would even work because of the BM> filesystem. Might be driven over to linux... or have a zillion partitions, and still not be able to handle large files... ;) BM>>> I didn't have time to update the hardware: update the Frontends BM>>> (viewing computers) to the current Ubuntu (18.04.3) and the MythTV BM>>> utility so left alone. Good news for our testing is Backend 2 (the BM>>> old/original computer doing the recording and storage) is still BM>>> recording shows and so can be used for our final testing. NB>>> Very useful... :) So, have you done that final testing yet, and NB>>> updated the hardware...? BM>> Yup! :) One had to have semi-major surgery: knew the power supply BM>> needed replacing as the fan froze some time back -- held off replacing BM>> as 'inconvenient' plus the major system change. Did put in the new BM>> PSU, checked, swapped the HDD for SSD (hard drive for a solid state BM>> one) -- now boots in around thirty seconds. That one is in the Ironing BM>> Room in the basement. NB>> All right... :) Nice when things work properly... :) BM> Yes. :) Could have changed the PSU and HDD-->SSD in one step but BM> prefer to do major (and sometimes minor) changes in steps -- just BM> easier troubleshooting should something go wrong. Possibly easier to backpedal if needed to that way, too... BM>> Will see about replacing the fan in the old PSU instead of buying a BM>> whole new PSU. NB>> Makes sense... and with it out of the computer, twill be easier NB>> to work with... ;) BM> Definitely, especially as I think the screws to open the PSU were BM> underneath! ...Will have to see what the price of a replacement BM> fan is: with another computer it's greatly cheaper to replace the CPU BM> fan/heatsink assembly than buy the replacement fan (!). That does happen from time to time.... :) BM>>> And I was surprised when the car started right up after my appointment. BM>>> Was either still raining or had just stopped, forgot. Probably the BM>>> heat of the engine and gravity pulling the splashed water down cleaned BM>>> the wires and removed the short. And did have the car checked and the BM>>> spark plug harness needed replacing: cracked insulation. NB>>> Which probably had been there before your forced puddle-drive... NB>>> ;) Just as well to find it sooner than later, when it might have NB>>> given you more grief... :) BM>> Right. I recall I left things for a while. Had a foggy period and BM>> the car didn't like that because of the moisture getting in to the BM>> cracks so that's when had the wiring harness replaced. NB>> So you probably would have found it sooner or later... this way NB>> at least you were warned to watch out for it... ;) BM> Yes, the cracked insulation on the sparkplug wires would have caused a BM> problem eventually. Yup... ttyl neb .... Never let a machine know you're in a hurry... --- EzyBlueWave V3.00 01FB001F * Origin: Tiny's BBS - http://www.tinysbbs.com (454:1/452) .