ネットワークレンダリングで『マネージャにジョブを受け取るためのディスク領域が足りません。』と出たときは・・・

今まで何の問題もなくBackburnerでネットワークレンダリングが出来ていたのに、ある日を境にレンダージョブをサブミットすると『マネージャにジョブを受け取るためのディスク領域が足りません。』と表示されるようになり、ネットワークレンダリングが出来なくなってしまいました。

色々調べて解決できたので今回はその対処法を紹介します。
環境はWindows 10 Proです。
環境は人それぞれ違うので設定は自己責任でお願いします。

解決策

エラーメッセージの『マネージャにジョブを受け取るためのディスク領域が足りません。』（英語版だと”Manager does not have enough disk space to receive job”）とネット検索すると、autodeskのサポートページが出てきました。
そこには三つの解決策が記載されていたので試してみたら二つ目で解決できました。

解決策①：ディスク容量の確認

レンダー出力の保存先のドライブを調べて、レンダーしたフレームを保存するのに十分なディスク容量があることを確認します。そうでない場合は、別のドライブの場所に切り替えます。

autodesk support

これは保存先に容量があるかを確認するだけです。

解決策②： IPVv6よりもIPv4を優先させる

このWebページにあるMicrosoft Fix itソリューションをダウンロードして実行することで、レンダリングファームのすべてのPCをIPv6よりもIPv4に優先するように設定します。

autodesk support

今回はこの方法で解決できましたが、実は難しそうだったので③を試してみて最後に②の解決策を試してみましたｗ
autodeskの説明にあるリンク先のツールは使用せず（なんとなく怖かったので）、コマンド入力で設定しました。方法については後程説明します。

解決策③：Backburnerをリセット

すべてのシステムでBackburnerをリセットしてみます。Backburnerのユーザ設定を既定にリセットする方法

autodesk support

Backburnerをリセットさせます。
この方法もすぐに試せますが、今回の私のケースでは原因ではありませんでした。

IPv6よりもIPv4を優先させる方法

通信の確認

先ずコマンドプロンプトを起動して

ping localhost

と、打ち込んで実行します。
するとIPv6で通信していることが確認できます。

DESKTOP-PC001 [::1]に ping を送信しています 32 バイトのデータ:
::1 からの応答: 時間 <1ms
::1 からの応答: 時間 <1ms
::1 からの応答: 時間 <1ms
::1 からの応答: 時間 <1ms
::1 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 0ms、平均 = 0ms 

『::1』というのがIPｖ6のことです。

通信の優先順位の確認

続いて通信の優先順位の確認をします。

 netsh interface ipv6 show prefixpolicies 

と、打ち込んで実行すると

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

と、帰ってきます。
優先順位が50と40の『::1/128』、『::/0』がIPv6で
優先順位が35の『::ffff:0:0/96』がIPv4のことです。

優先順位をIPv4が一番上に来るように設定します。

IPv4を優先させるように設定

では確認が出来たところで設定を変更していきます。
コマンドプロンプトを一旦閉じて、コマンドプロンプトを右クリックから管理者権限で実行します。

優先順位を指定します。

netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 55 4
netsh interface ipv6 set prefixpolicy ::1/128 50 0
netsh interface ipv6 set prefixpolicy ::/0 40 1
netsh interface ipv6 set prefixpolicy 2002::/16 30 2
netsh interface ipv6 set prefixpolicy 2001::/32 5 5
netsh interface ipv6 set prefixpolicy fc00::/7 3 13
netsh interface ipv6 set prefixpolicy fec0::/10 1 11
netsh interface ipv6 set prefixpolicy 3ffe::/16 1 12
netsh interface ipv6 set prefixpolicy ::/96 1 3

と、打ち込み実行します。
こうすることで、IPv4の優先順位が55に変更されて、優先順位が一番上に来ます。
確認してみましょう。

 netsh interface ipv6 show prefixpolicies 

と、打ち込んで実行（先程も打ち込んだヤツ）

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        55      4  ::ffff:0:0/96
        50      0  ::1/128
        40      1  ::/0
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

するとIPv4が一番上に来たことが確認できました。
通信の確認もしてみましょう。

ping localhost

と、打ち込んで実行（これも先程も打ち込んだヤツ）

DESKTOP-PC001 [127.0.0.1]に ping を送信しています 32 バイトのデータ:
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 0ms、平均 = 0ms

通信がIPv4になっていることが分かりました。

この状態でBackburnerからレンダージョブをサブミットすると問題なくサーバーに送り、ジョブが走ってくれるようになりました！

元に戻す方法

変えた設定を元に戻す場合は、管理者権限で実行したコマンドプロンプトで

 netsh interface ipv6 reset 

と、打ち込み、マシンを再起動させるとリセットできます。

最後に

この方法でネットワークレンダリングが復活しました！
コマンドプロンプトはどうしても抵抗があり、変更するのは怖いというイメージがありますが調べて何とかなりましたｗ。
環境は人それぞれ違うのでこのような設定は自己責任でお願いします。

最近プロバイダーを変更してネット環境を変えたのが原因のようです。Backburnerでジョブをサブミットする前にサーバーを見ることが出来たので、通信のエラーとは最初思わなくて再インストールとかいろいろ遠回りをしてしまいました。
とりあえず一件落着です。