wget이 스트리밍 mp3를 올바르게 다운로드할 수 없습니다.

이것은 실시간 스트림입니다. 회복할 시작이나 고정된 위치가 없기 때문에 "회복"이라는 전체 개념이 적용되지 않습니다. 현재 스트리밍 중인 모든 데이터를 얻을 수 있습니다.

그러나 wget이것을 몰랐습니다. 네트워크 장애 후 복구 시도는 다음과 같습니다.

1. wget파일의 크기를 알아보세요. 서버가 재개 가능한 전송을 지원하는 경우 wget소스 파일의 중간부터 전송을 재개해야 하지만 서버에 이 파일이 없고 서버가 재개 가능한 전송을 지원하지 않으므로 이 방법은 실패합니다.
2. 복원 시도가 실패했으므로 wget복원을 받은 것으로 간주됩니다.동일한 데이터처음부터. 폐기되는 양이 이전 파일 크기에 도달할 때까지 데이터를 폐기합니다. 그런 다음 파일에 새 데이터를 추가하기 시작합니다. 파일이 커지기 시작하는 시점입니다.

실제로 연결에 문제가 있으면 스트림의 일부를 놓치는 것이 아니라 스트림의 일부를 놓치는 것입니다. 또한 wget동일한 데이터를 두 번째로 수신했다고 가정하기 때문에 저장할 수 있었던 데이터를 놓칠 수도 있습니다 .

이 문제를 해결하려면 다음을 시작하고 필요에 따라 계속 다시 시작하십시오.

wget http://sj128.hnux.com/sj128.mp3 -O - >> "file.mp3"

(원하시면 다른 옵션도 가능합니다.) 수신된 모든 콘텐츠는 wget파일에 추가됩니다. 스트림의 일부 세그먼트를 놓친 경우 결과 파일은 분명히 "분쇄된" 콘텐츠를 저장하게 됩니다. 내 테스트에서 VLC는 이러한 파일을 재생하는 데 기술적인 문제가 없었습니다.

참고: 언제든지 .txt 파일을 사용하여 파일을 0 크기로 줄일 수 있습니다 : > file.mp3. 주어진 파일의 끝을 항상 찾기 wget때문에 이는 실행 중에도 작동합니다(참조:>>이것).

---

wget"파일" 유형 충돌을 피하기 위해 완전히 다른 파일 이름으로 완전히 새로운 파일을 시작했지만 [...] 여전히 새 파일을 쓰지 않았습니다!

재현할 수 없습니다. 내 것은 wget새 파일을 썼습니다.

더 나은 할 일이 없었기 때문에 나는 고용주의 대역폭 중 일부를 게임에 소비하고 있었습니다.

다운로드하려는 파일이 230MiB보다 큽니다. 전원을 끄기 전의 모습입니다.

상대방의 다운로드 속도는 15kbps로 제한되므로 연결이 "불안정한" 경우(보시다시피) 연결이가다감소.

복원을 하려고 했더니 wget상대측 서버가 복원을 지원하지 않는 것 같아서 wget그냥 처음으로 돌아가서 다시 시작했습니다.

이는 완전히 예상되는 동작입니다. 특정 조건 하에서 페이지에서 man가져옵니다 wget.

 Note that -c only works with FTP servers and with HTTP servers that support the 
"Range" header.

파일이 커지지 않습니다.

1. 연결이 끊어지는 간격은 (아마도 30,000MiB / 15kBps) = 30분입니다.

2. wget연결이 끊어질 때마다 파일의 처음부터 시작해야 합니다. 파일 관리자는 마지막으로 사용된 최대값만 확인하고 해당 크기를 보고하며, wget처음부터 다시 시작하여 연결이 끊어질 때까지 원본 파일을 단계별로 덮어쓰게 됩니다... 다시... 다시 ......그리고... ...

10초 동안 달리고 wget멈춘 다음 20초 동안 달리세요. 두 번째 실행에서 다운로드 크기가 이전 크기를 초과하면 파일 크기가 다시 증가하는 것을 볼 수 있습니다.

구체적으로 문서화되어 있지는 않지만 -c(적어도 찾을 수는 없음) 특정 조건에서 이러한 동작이 예상됩니다. man wget관련 섹션을 읽어보세요-nc